Dans de nombreuses équipes web et IoT, le Serveur FTP reste associé à l’époque des modems et des sites vitrines. Pourtant, dès qu’un site WordPress se bloque sur une erreur 500, qu’un firmware doit être mis à jour en urgence ou qu’un prestataire change, tout le monde cherche frénétiquement les accès FTP ou SFTP.
Le sujet n’est donc pas théorique : il touche directement la capacité d’une équipe à reprendre la main sur ses fichiers, qu’ils soient hébergés chez un infogérant, dans un cloud public ou sur un simple NAS de bureau.
Ce texte prend le problème par le concret : rappeler la Définition FTP, montrer comment installer un Serveur FTP qui tient la route, puis comparer sans langue de bois les Alternatives FTP sécurisées comme SFTP et FTPS.
L’objectif n’est pas de célébrer une technologie ancienne, mais de dire quand le Protocole FTP reste utile, quand il devient dangereux, et comment basculer progressivement vers des pratiques plus robustes, en particulier pour les sites WordPress et les infrastructures industrielles exposées.
En bref
- FTP classique transporte les identifiants et les données en clair : à réserver aux environnements de labo isolés ou à bannir.
- SFTP, basé sur SSH (port 22), constitue aujourd’hui le choix par défaut pour tout Transfert de fichiers administré, qu’il s’agisse de WordPress, de CI/CD ou d’IoT.
- FileZilla reste la valeur sûre côté client et, en version serveur, une option crédible pour monter un serveur de fichiers gratuit sous Windows.
- Sur Linux, un serveur SFTP sérieux s’appuie sur OpenSSH, éventuellement complété par des outils comme ProFTPD ou VsFTPd, selon les politiques internes.
- Pour les migrations et les plans de secours, garder des accès SFTP documentés vaut souvent plus qu’une promesse de support 24/7.
Serveur FTP et Protocole FTP pour le web et l’IoT : de quoi parle-t-on exactement ?
Avant de parler Installation FTP, il faut clarifier ce qui se cache derrière le terme souvent flou de Serveur FTP. En pratique, il s’agit d’un logiciel à l’écoute sur un port réseau, généralement le port 21, qui accepte des connexions d’un client pour un Transfert de fichiers dans un sens comme dans l’autre.
On dépose, on télécharge, on renomme, on supprime, un peu comme sur un partage de fichiers local, sauf que tout passe par le réseau TCP/IP.
Historiquement, le Protocole FTP a été l’un des tout premiers standards d’Internet. La contrepartie est claire : à l’origine, aucun chiffrement, aucune notion moderne de durcissement. Identifiant et mot de passe passent en texte clair sur le réseau. Sur un wifi public ou un LAN un peu peuplé, un simple outil d’écoute suffit à récupérer des accès. C’est précisément ce point qui a poussé les hébergeurs à couper progressivement le FTP simple au profit du SFTP et du FTPS.
Concrètement, lorsqu’un développeur ouvre FileZilla, Cyberduck ou WinSCP, il voit deux colonnes : à gauche ses fichiers locaux, à droite ceux du serveur. Il renseigne un hôte, un identifiant, un mot de passe et un port. Sans ces quatre éléments, aucun accès. C’est ce qui explique pourquoi la maîtrise des identifiants FTP ou SFTP détermine la capacité à reprendre le contrôle sur un site, même quand l’agence a disparu ou qu’un prestataire change de cap.
Les usages restent très variés. Dans le web, FTP ou SFTP sert à envoyer un thème WordPress, corriger un fichier .htaccess ou pousser un correctif sur un script. Dans l’IoT, il arrive encore que des firmwares soient déposés sur un Serveur FTP pour être récupérés ensuite par des objets connectés en tâche planifiée. Cette pratique survit surtout dans des architectures historiques ou isolées. Pour des systèmes modernes et exposés, la Sécurité FTP impose de réfléchir à d’autres maillons, par exemple des API sécurisées ou des mécanismes OTA plus avancés.
Autre point souvent négligé : un Serveur FTP n’est pas un « disque magique » sans limites. Il s’inscrit dans une stratégie plus large de gestion du stockage, des droits d’accès, des journaux et de la sauvegarde. Les erreurs classiques sont connues : comptes partagés entre plusieurs prestataires, absence de quotas, logs non surveillés. Lorsqu’un incident survient, ces angles morts compliquent énormément les investigations et les restaurations.
Au fond, FTP n’est qu’un tuyau. La vraie question, pour une PME, un hébergeur ou une équipe produit, devient : qui a le droit d’y brancher quoi, et comment tracer ce qui y circule. Les sections suivantes entrent dans le détail de ces choix, côté Linux, côté Windows et côté alternatives chiffrées.
Installer un Serveur FTP ou SFTP sous Linux pour un usage sérieux
Dès qu’il s’agit d’héberger soi-même des services, Linux garde une avance nette. Les distributions courantes intègrent nativement OpenSSH, ce qui signifie qu’un serveur SFTP de base fonctionne souvent dès l’installation. Pour un usage professionnel, la question n’est pas de savoir s’il marche, mais comment le configurer pour qu’il reste sous contrôle, malgré les années et les changements d’équipes.
Sur un serveur Debian ou Ubuntu utilisé pour WordPress, la configuration typique consiste à activer SFTP via le sous-système prévu dans sshd_config, à limiter l’accès à un groupe dédié et à chrooter les utilisateurs dans un répertoire précis. Ce confinement évite qu’un compte SFTP puisse se promener dans l’ensemble du système, ce qui est déjà une forme minimale de Sécurité FTP adaptée aux environnements mutualisés.
Quand un vrai Serveur FTP est demandé pour compatibilité avec des clients anciens ou des équipements industriels, plusieurs briques existent : ProFTPD, Pure-FTPd, VsFTPd, DrFTPD ou Glftpd. Chacune a sa culture. ProFTPD se rapproche de la logique Apache avec une configuration très souple, VsFTPd vise une posture plus stricte, Pure-FTPd cherche un compromis entre performance et simplicité. Pour une PME qui ne dispose pas d’un administrateur temps plein, choisir un logiciel trop ésotérique finit souvent en configuration figée pendant dix ans, avec des comptes jamais révoqués.
Un point revient régulièrement chez les hébergeurs qui gèrent leurs propres machines dans le cloud. Beaucoup d’administrateurs débutants oublient de restreindre l’accès réseau à ces services. Résultat : port 21 exposé à Internet entier, parfois même sans TLS. Une simple règle de pare-feu réduisant le FTP ou SFTP à une ou deux plages d’IP d’administration change complètement le niveau de risque. Pour un hébergement chez un acteur comme OVHcloud, combiner un filtrage réseau propre avec des comptes SFTP nominatifs évite déjà une grande partie des mauvaises surprises.
Autre terrain où FTP persiste : les flux automatisés entre systèmes d’information. Beaucoup de logiciels métiers savent encore uniquement « pousser » un fichier via FTP vers un répertoire surveillé. Dans ces cas-là, interdire FTP du jour au lendemain n’est pas réaliste. Une approche pragmatique consiste à isoler un Serveur FTP dédié, à y activer le chiffrement (FTPS), à forcer les mots de passe robustes et à surveiller les journaux de connexion. C’est moins élégant qu’une API REST, mais cela reste plus sain qu’un FTP nu ouvert sur le monde.
L’enseignement principal, côté Linux, tient en une phrase : un serveur SFTP propre, appuyé sur OpenSSH et quelques groupes d’utilisateurs bien pensés, couvre la majorité des besoins modernes. FTP classique ne devrait apparaître que comme une concession liée à des contraintes d’interopérabilité, assortie de garde-fous explicites.
FileZilla Server et les options FTP sous Windows pour les équipes web
Côté Windows, le paysage a longtemps été plus confus. Entre l’implémentation FTP d’IIS, les solutions propriétaires et une diversité de petits serveurs gratuits, les équipes se retrouvaient parfois avec plusieurs instances différentes bricolées au fil des années. En pratique, pour un usage raisonné, quelques noms reviennent systématiquement : FileZilla Server, Drftpd, Ioftpd, Titan FTP Server ou TYPSoft FTP Server.
Pour un serveur de fichiers gratuit destiné à héberger des sites ou des partages techniques internes, FileZilla Server reste une valeur de base. L’installation se fait en quelques minutes, l’interface graphique permet de créer des utilisateurs, de définir des racines de répertoires et de choisir les ports utilisés. Le danger vient justement de cette facilité. Beaucoup d’administrateurs créent un compte générique « web », partagé entre agence, stagiaire et freelance, puis oublient ce compte pendant des années.
Lorsqu’une entreprise fictive comme « Atelio Industrie » confie son site institutionnel à une agence et donne un unique compte FTP générique, la situation devient délicate dès que l’agence change. Impossible de savoir qui a encore l’identifiant, impossible de tracer les connexions, et une tentation forte de garder le même compte « pour ne pas casser les scripts ». C’est tout l’inverse d’une bonne hygiène. Windows ou pas, la pratique recommandée reste la même : comptes nominatifs, droits minimaux, rotation régulière des mots de passe ou, mieux, authentification par clé.
Sur Windows Server, beaucoup de responsables IT sous-estiment la puissance de SFTP déjà disponible via les implémentations OpenSSH récentes. Dans un scénario simple, il est tout à fait envisageable de se passer de FTP classique et de n’offrir qu’un accès SFTP à quelques comptes. FileZilla Server peut alors être réservé aux rares cas qui exigent vraiment la compatibilité FTP, avec des règles claires : TLS obligatoire, ports limités, pas d’accès anonyme.
Côté client, l’usage reste identique quel que soit le système. Un développeur ouvre FileZilla Client, va dans le gestionnaire de sites, crée une nouvelle entrée avec « Protocole : SFTP », renseigne host, login, mot de passe, port 22 et se connecte. Si cela échoue, les vérifications classiques s’imposent : IP bloquée par le pare-feu, SFTP non activé chez l’hébergeur, mauvais mot de passe ou mauvaise clé SSH. Documenter ces points dans une procédure interne évite les allers-retours inutiles en pleine urgence.
Sur Windows comme sur Linux, la tendance nette consiste à utiliser FTP uniquement comme roue de secours ou pour de l’intégration avec des systèmes anciens. Tout ce qui touche au site vitrine, à l’e-commerce ou aux applications critiques devrait passer sur SFTP dès que possible. Le coût d’un basculement bien préparé reste largement inférieur à celui d’une compromission due à un FTP non chiffré exposé depuis des années.
WordPress, .htaccess, erreurs 500 : usages concrets de FTP et SFTP en production
Dès que l’on parle de sites WordPress en production, le couple FTP/SFTP sort du domaine théorique. Les incidents parlent d’eux-mêmes : extension mal codée qui déclenche une erreur 500, fichier wp-config.php corrompu, thème enfant déployé trop vite, migration incomplète. Dans tous ces cas, un accès SFTP fonctionnel fait la différence entre un site remonté en quinze minutes et un week-end entier passé avec un site hors ligne.
Le cas le plus courant consiste à corriger un fichier .htaccess qui bloque tout. Une simple règle de redirection, mal écrite, suffit à mettre un serveur Apache à genoux. Avec un client comme FileZilla, le développeur se connecte, télécharge le fichier défectueux, le corrige en local et le renvoie. Pour aller plus loin et mettre en place des redirections propres, certains s’appuient sur des ressources spécialisées comme les guides RedirectMatch 301 disponibles en ligne, par exemple sur cet article dédié aux règles .htaccess.
Autre usage récurrent : désactiver un plugin qui fait planter le site. Quand l’interface d’administration WordPress est inaccessible, le seul levier consiste à renommer le répertoire du plugin fautif via SFTP. À la prochaine requête, WordPress ne le trouve plus et revient à un état fonctionnel. Cette manoeuvre, qui prend moins de deux minutes, reste paradoxalement méconnue de nombreux propriétaires de sites, parce qu’ils n’ont jamais récupéré leurs identifiants FTP/SFTP auprès de leur hébergeur.
Pour les migrations, le schéma est similaire. Une équipe exporte la base de données par un outil standard, puis transfère l’intégralité du répertoire du site via SFTP d’un hébergeur à un autre. Chez un prestataire comme OVHcloud, o2switch ou Infomaniak, les interfaces d’administration facilitent déjà certains transferts, mais garder une méthode SFTP manuelle donne une liberté supplémentaire. En cas de problème avec l’outil d’import automatique, il reste possible de reconstruire le site « à l’ancienne ».
Une autre évolution discrète mérite d’être soulignée. Avec WordPress, de plus en plus d’installations permettent l’ajout de thèmes et de plugins directement depuis l’interface, sans besoin de FTP, dès que les permissions de fichiers sont correctement posées. Cela allège le quotidien, mais ne remplace pas un accès SFTP complet pour gérer les cas d’école : suppression d’un répertoire resté orphelin, upload d’un thème sur mesure, analyse d’un fichier suspect laissé par une intrusion.
Au final, la question n’est pas de savoir si FTP ou SFTP est « moderne », mais de vérifier si l’équipe en charge du site dispose des moyens de s’en servir sans dépendre d’un tiers. Un plan de secours raisonnable inclut les identifiants SFTP, une procédure simple pour corriger .htaccess, une méthode pour geler un plugin à distance et une organisation des répertoires propre. C’est peu spectaculaire, mais extrêmement rentable en jour de crise.
FTP, SFTP, FTPS : tableau comparatif, alternatives et bonnes pratiques de sécurité
Sur le papier, les sigles se ressemblent. Dans la pratique, mélanger FTP, FTPS et SFTP crée des incompréhensions inutiles entre développeurs, administrateurs et clients. Pour remettre de l’ordre, un tableau simple aide souvent plus qu’un long discours. Les différences portent sur trois axes : protocole sous-jacent, ports utilisés, façon dont la Sécurité FTP est gérée et cas d’usage adaptés.
| Protocole | Port par défaut | Chiffrement | Cas d’usage recommandés | À éviter pour |
|---|---|---|---|---|
| FTP | 21 | Aucun | Tests en labo isolé, équipements anciens non compatibles SFTP | Sites web publics, données sensibles, accès via Internet |
| FTPS | 21 + ports passifs | SSL/TLS | Interop avec clients hérités nécessitant FTP, mais avec chiffrement | Environnements où la gestion de ports multiples est compliquée |
| SFTP | 22 | SSH | Administration de sites WordPress, déploiements CI/CD, transferts réguliers | Équipements n’acceptant que FTP classique |
Pour les sites WordPress et les projets cloud, la recommandation est nette : SFTP par défaut. Un seul port, un écosystème mature, une intégration naturelle avec les clés SSH et les mécanismes d’authentification modernes. FTPS garde son intérêt pour les organisations qui doivent composer avec des logiciels ne parlant que FTP, mais qui acceptent un lien chiffré. FTP pur, lui, ne devrait rester qu’un outil de laboratoire derrière un pare-feu strict.
Dans certaines équipes DevOps, FTP a même disparu au profit d’autres outils comme SCP ou rsync, appelés directement depuis des pipelines d’intégration continue. Pour ceux qui souhaitent creuser cette voie, des ressources détaillent déjà comment tirer parti du transfert SSH dans des scripts automatisés, par exemple dans des guides sur SCP Linux comme celui disponible sur cette page dédiée aux transferts SSH. Le principe reste le même : privilégier des protocoles qui ne laissent pas traîner de mots de passe en clair sur le réseau.
Les bonnes pratiques minimales pour un Serveur FTP ou SFTP exposé sont assez stables. Côté chiffrement, refuser les suites obsolètes, imposer TLS récent pour FTPS et des algorithmes sérieux pour SSH. Côté comptes, bannir l’anonyme, limiter les droits à un répertoire donné, activer une rotation raisonnable des identifiants et, dès que possible, passer aux clés SSH. Côté réseau, filtrer les IP autorisées, surveiller les journaux et mettre en place une alerte en cas de tentatives nombreuses d’authentification ratée.
Les équipes qui prennent le temps de poser ce cadre se rendent vite compte d’un effet secondaire positif. Le Serveur FTP devient un service documenté, identifié, intégré dans la cartographie globale du système d’information. Du coup, lors d’un projet de refonte ou d’une migration vers un cloud plus moderne, il est plus simple de décider ce qu’on garde, ce qu’on remplace par du S3 ou par une API, et ce qui mérite d’être purement supprimé.
Serveur FTP gratuit, automation et place de ces outils dans une architecture moderne
Reste une question un peu taboue : un Serveur FTP gratuit a-t-il encore sa place dans une architecture pensée pour durer, alors que les stockages objets, les dépôts Git et les API occupent le devant de la scène. La réponse dépend moins de la mode technologique que des profils présents dans l’équipe et des contraintes du terrain. Un bureau d’études avec des partenaires industriels dispersés n’a pas les mêmes besoins qu’une agence web qui pousse tout sur un GitLab auto-hébergé.
Dans un scénario réaliste, un site industriel hébergé sur un cloud public continue de s’appuyer sur un stockage orienté objet pour les médias, sur un dépôt Git pour le code, mais garde un petit Serveur SFTP pour quelques opérations sensibles : échange ponctuel de fichiers lourds avec un fournisseur, dépannage d’un site WordPress satellite, récupération d’archives. Le coût de ce service reste marginal, côté cloud comme côté temps d’administration, comparé à la souplesse qu’il offre.
La frontière entre FTP et automation se fait d’ailleurs plus poreuse. Certains pipelines CI déclenchent des déploiements en SFTP vers des serveurs encore gérés de manière classique par les clients. D’autres scripts supervisent la présence de nouveaux fichiers déposés en SFTP par des machines ou des partenaires, puis déclenchent des traitements. Même si l’interface graphique de FileZilla reste très utilisée, les usages automatisés progressent peu à peu.
Pour une équipe qui construit une nouvelle plateforme en 2026, la bonne approche consiste à considérer FTP et SFTP comme une brique d’accès parmi d’autres, au même titre qu’un accès SSH ou qu’une console web. En architecture, mieux vaut prévoir un point d’entrée SFTP propre, clairement documenté, que de se retrouver plus tard à ouvrir en catastrophe un FTP anonyme parce qu’un partenaire n’a que cet outil en magasin. Beaucoup de sur-incidents viennent justement de ces ouvertures de dernière minute.
En parallèle, les solutions d’hébergement ont fait des progrès notables sur leurs consoles. OVHcloud, Hostinger ou d’autres proposent des interfaces web pour déposer des fichiers, gérer les permissions et déclencher des sauvegardes. Tant mieux, cela simplifie la vie de nombreux utilisateurs. Mais ceux qui ont déjà vu une interface d’hébergement indisponible en plein week-end savent pourquoi garder un accès SFTP bas niveau reste une assurance prudente.
Au bout du compte, ce qui sépare les architectures robustes de celles qui vieillissent mal n’est pas la présence ou l’absence de FTP. C’est la clarté avec laquelle les équipes ont défini les protocoles autorisés, les usages prévus et la façon de les faire évoluer. Un Serveur FTP ou SFTP bien borné, surveillé, intégré dans une stratégie plus large, peut rendre service longtemps sans devenir un boulet technique.
Quelle est la différence principale entre FTP, FTPS et SFTP pour un site WordPress ?
FTP transfère les identifiants et les fichiers en clair sur le réseau, ce qui le rend inadapté à un site WordPress exposé. FTPS ajoute une couche de chiffrement TLS au protocole FTP, mais implique une gestion plus complexe des ports. SFTP, lui, repose sur SSH, utilise le port 22 et chiffre l’ensemble du flux ; c’est aujourd’hui la solution à privilégier pour administrer un WordPress, corriger un .htaccess ou désactiver un plugin défaillant.
Un serveur FTP gratuit comme FileZilla Server est-il suffisant pour un usage professionnel ?
Oui, à condition d’être configuré sérieusement. FileZilla Server peut convenir comme serveur de fichiers gratuit pour un petit hébergement ou un intranet si l’accès anonyme est désactivé, si TLS est activé pour FTPS et si les comptes sont strictement limités à leurs répertoires. Pour les usages exposés, il reste préférable de proposer SFTP via OpenSSH, quitte à garder FileZilla Server uniquement pour certains flux hérités.
Faut-il encore accepter des connexions FTP non chiffrées sur Internet en 2026 ?
Pour un environnement connecté à Internet, la réponse est non dans l’immense majorité des cas. FTP non chiffré expose les identifiants et les données à toute écoute réseau. Les rares contextes où FTP simple reste tolérable concernent des réseaux de test isolés ou des équipements très anciens situés derrière un pare-feu hermétique. Pour un site web, pour de l’IoT ou pour des fichiers métiers, SFTP ou FTPS doivent devenir la norme.
Comment choisir entre SCP, SFTP et un client FTP graphique pour les déploiements ?
Pour des déploiements automatisés depuis une chaîne CI/CD, SCP ou SFTP appelés depuis des scripts conviennent mieux, car ils s’intègrent naturellement dans les pipelines. SFTP offre en plus un catalogue de fonctionnalités plus riche (listage, reprise sur erreur). Pour les opérations ponctuelles, de dépannage ou d’exploration, un client graphique comme FileZilla reste très pratique, surtout pour les profils moins techniques.
Que faire si un prestataire refuse de fournir les accès FTP ou SFTP d’un site ?
Un site hébergé au nom de l’entreprise doit rester sous son contrôle technique. En cas de blocage, il est recommandé de reprendre la main directement auprès de l’hébergeur, de demander la régénération de comptes SFTP administrateur et de planifier au plus vite une migration ou une mise à plat des accès. Continuer avec un prestataire qui retient les identifiants expose à un risque de dépendance et complique toute reprise en urgence.