Top 8 des logiciels serveur SFTP
Nous avons comparé 8 implémentations de serveur SFTP dans un environnement de test contrôlé, en nous concentrant sur les performances de transfert, la concurrence, la surcharge de connexion, les charges de petits fichiers, l’efficacité des ressources et l’expérience opérationnelle.
Si vous utilisez déjà SFTP mais souhaitez une approche de transfert de fichiers plus adaptée à l’entreprise, envisagez les solutions MFT.
Résultats du benchmark des logiciels serveur SFTP
Performances de transfert
Coût opérationnel
Remarque : des scores plus faibles indiquent de meilleures performances.
Consultez la méthodologie pour en savoir plus sur notre environnement de test et nos processus de notation.
SFTPGo
SFTPGo est un serveur SFTP basé sur Go distribué sous forme de binaire autonome, avec une configuration disponible via JSON, des variables d’environnement, une interface d’administration web et une API REST. Il prend en charge le stockage local, S3, le stockage Google Cloud et les backends Blob Azure, et inclut des fonctionnalités opérationnelles telles que les quotas, les règles d’événement, l’authentification à deux facteurs et les métriques Prometheus.
Figure 1 : exemple de connexion SFTPGo.
Il a nécessité une configuration minimale pendant le benchmark. Le principal problème était une limite de connexions par hôte par défaut qui rejetait les écritures lors du test sur petits fichiers, mais la désactivation de cette limite a résolu le problème.
Une fois configuré, SFTPGo a combiné des performances de transfert élevées avec la latence de négociation la plus faible du groupe testé (25 ms au p50, soit moins de la moitié du serveur suivant le plus rapide) et une consommation mémoire par session réduite (0.091 Mo, environ 145× inférieure à celle d’OpenSSH). Ses performances multi-flux ont également bien évolué sans adopter un modèle de type processus par connexion. Cette combinaison en a fait le résultat généraliste le plus solide de ce benchmark.
Figure 2 : tableau de bord d’administration SFTPGo.
HPN-SSH
HPN-SSH est un dérivé d’OpenSSH axé sur les performances. Il s’installe à côté des binaires OpenSSH système et conserve essentiellement le même modèle de configuration, en ajoutant un comportement spécifique HPN destiné principalement aux réseaux à large bande passante et à latence élevée. Pour les administrateurs familiers d’OpenSSH, les différences opérationnelles sont faibles.
Le paquet a automatiquement démarré un service hpnssh.service lors de l’installation, qui a occupé le port attribué à l’instance de benchmark OpenSSH jusqu’à ce que le service soit arrêté et masqué. En dehors de ce conflit, il s’est comporté comme OpenSSH.
Il a fourni le meilleur résultat de téléversement mono-flux (167.4 Mo/s, bien que MINA à 166.9 Mo/s et SFTPGo à 165.3 Mo/s aient terminé à moins de 1,3 % d’écart) et le démarrage de processus le plus rapide du benchmark (0.88 s), mais a hérité du modèle de mémoire par processus d’OpenSSH. Sous la limite de mémoire imposée de 6 Go, il a échoué lorsque le test de sessions concurrentes a atteint 300 connexions.
Le benchmark s’est déroulé entièrement en bouclage local et ne teste donc pas l’environnement dans lequel HPN-SSH est spécifiquement conçu pour se distinguer. Une latence réseau proche de zéro supprime la majeure partie de la contrainte de produit bande passante-délai ciblée par ses modifications de fenêtre plus large. Son avantage WAN reste donc hors du champ de ces résultats.
Apache MINA SSHD
Apache MINA SSHD diffère des autres car il s’agit d’une bibliothèque Java, contrairement à un serveur SFTP prêt à l’emploi. Pour le benchmark, nous avons dû écrire un serveur en utilisant les composants sshd-core et sshd-sftp, puis le compiler en tant que JAR autonome avec Maven. L’application contrôle les clés d’hôte, l’authentification, la prise en charge SFTP et la configuration des chiffrements, plutôt qu’un fichier de configuration serveur classique.
Cela a demandé plus de travail de configuration que n’importe quel démon packagé. La compilation a nécessité une cible de compilateur Java moderne explicite, et l’authentification Ed25519 a nécessité une dépendance supplémentaire. L’authentificateur standard à clés autorisées a également rejeté le fichier de clé du benchmark en raison de ses contrôles de permissions ; le serveur de test a donc utilisé un chemin de comparaison de clé personnalisé.
Une fois en cours d’exécution, MINA s’est toutefois bien comporté : il a produit le meilleur résultat en téléchargement (172.4 Mo/s), une faible consommation mémoire par session et la deuxième meilleure efficacité CPU mesurée lors du test d’efficacité des ressources (132,8 % par Gbit/s, derrière les 119,4 % d’OpenSSH). La principale pénalité à l’exécution était le temps de démarrage de la JVM (3.39 s jusqu’à la première connexion). Il constitue donc un composant d’implémentation intéressant pour les applications nécessitant un endpoint SFTP embarqué, mais pas un substitut direct à un produit SFTP destiné aux administrateurs.
OpenSSH
OpenSSH a servi d’implémentation de référence. Il était présent sur le système de test Ubuntu et n’a nécessité aucune installation de serveur supplémentaire. SFTP est exposé via internal-sftp, tandis que les utilisateurs, les clés publiques, les règles chroot et les contrôles d’accès utilisent les mécanismes standard de comptes OpenSSH et de sshd_config.
Les problèmes opérationnels étaient des problèmes OpenSSH bien connus, et non une instabilité du sous-système SFTP lui-même. Des propriétés ou des permissions incorrectes déclenchaient StrictModes, et le service systemd HPN-SSH occupait initialement le port du benchmark. Après suppression de ce conflit, le serveur a fonctionné de manière constante.
OpenSSH a traité la charge de petits fichiers mieux que toute autre implémentation testée (4 466 fichiers par seconde, 42 % d’avance sur le serveur suivant le plus rapide) et a enregistré le coût CPU par unité de débit le plus bas, à 119,4 % par Gbit/s, mais son architecture de type processus par connexion a consommé comparativement plus de mémoire par session active (13.283 Mo).
Ses résultats de débit sur fichiers volumineux nécessitent une réserve supplémentaire : cette instance de benchmark écrivait dans le répertoire personnel de l’utilisateur système sur disque, alors que les autres serveurs testés utilisaient tmpfs. Ses valeurs de débit absolu T1 et T2, ainsi que le chiffre de CPU par Gbit/s normalisé par rapport à elles, ne doivent donc pas être traitées comme directement équivalentes au reste du panel.
ProFTPD
ProFTPD fournit SFTP via mod_sftp. Il ne traite pas SFTP comme son protocole principal. Son système de configuration de type Apache est mature et flexible, et le serveur plus large peut combiner FTP, FTPS et SFTP avec une authentification SQL ou LDAP et des contrôles d’accès granulaires.
Il a également été le serveur le plus difficile à configurer au cours de ce benchmark. mod_sftp a dû être chargé explicitement, la politique d’écrasement par défaut bloquait les téléversements, la validation du shell affectait l’utilisateur du benchmark et un processus ProFTPD obsolète empêchait une instance suivante de se lier à son port.
Son chemin SFTP a produit le débit de téléchargement le plus faible (77.2 Mo/s) et de loin la latence de négociation la plus élevée parmi les serveurs mesurés (423 ms au p50, soit 3.6× le serveur suivant le plus lent). L’exception était la scalabilité des flux parallèles : le débit agrégé a augmenté sensiblement à mesure que la concurrence augmentait, atteignant 3.51× le débit mono-flux à quatre flux, ce qui a donné à ProFTPD le meilleur ratio de scalabilité de ce test. Ces résultats sont plus pertinents dans les environnements qui ont besoin de ses capacités multi-protocoles matures que dans les déploiements choisissant un serveur spécifiquement pour les performances SFTP.
SFTPPlus
SFTPPlus est une plateforme commerciale de transfert de fichiers géré basée sur Python et Twisted. Elle est livrée avec son propre environnement d’exécution Python et utilise un format de configuration INI lisible. En plus de SFTP, elle prend en charge FTPS, HTTPS et WebDAV, ainsi que des fonctions d’administration, d’automatisation, d’audit, d’intégration d’annuaire et de haute disponibilité attendues d’un produit MFT.
L’installation elle-même a été simple, mais la gestion des processus a introduit plusieurs problèmes spécifiques au benchmark. Le démarrage en tant que root a nécessité un paramètre de compte explicite, le lanceur au premier plan dépendait d’une exécution depuis le répertoire d’installation et le nom du processus à l’exécution différait de celui attendu par la logique de surveillance initiale.
Les performances reflétaient des priorités différentes de celles des serveurs axés sur le débit : SFTPPlus a présenté une consommation mémoire incrémentale par session exceptionnellement faible (0.028 Mo, la plus faible mesurée) et une bonne latence d’établissement de connexion (52 ms au p50), mais des téléversements de fichiers volumineux relativement lents (41.8 Mo/s), un traitement des petits fichiers (244 fichiers par seconde) et un démarrage de processus lent (7.49 s, plus du double du serveur suivant le plus lent).
Wing FTP Server
Wing FTP Server est un serveur natif commercial doté d’une interface d’administration web et prenant en charge FTP, FTPS, SFTP, HTTP et HTTPS. La configuration est organisée autour de domaines et d’utilisateurs, l’interface web servant de principal chemin de gestion ; une configuration XML et une interface console basée sur Lua sont également disponibles.
Figure 3 : tableau de bord d’administration Wing FTP.
L’interface graphique était plus facile à aborder que la plupart des configurations textuelles, mais plusieurs comportements ont compliqué l’automatisation. L’appel de création de domaine Lua a échoué à plusieurs reprises sans erreur utile ; il a rejeté une clé client Ed25519. En revanche, RSA-3072 fonctionnait, et un mappage de répertoire personnel créé via l’interface graphique ne persistait pas jusqu’à ce que nous l’ajoutions manuellement.
Les performances mesurées étaient nettement asymétriques : les téléchargements étaient considérablement plus rapides que les téléversements (129.7 Mo/s contre 34 Mo/s, soit un écart de 3.8× et le chiffre de téléversement le plus faible du benchmark), le traitement des petits fichiers était le plus lent du groupe (90 fichiers par seconde, contre 244 pour le suivant le plus lent) et la consommation CPU par rapport au débit atteint était élevée (433,7 % par Gbit/s, presque le double du serveur suivant le plus élevé). L’utilisation de la mémoire par session, en revanche, est restée faible (0.107 Mo) car le serveur utilise une architecture à threads plutôt qu’une architecture de type processus par connexion.
Figure 4 : éditeur d’utilisateurs Wing FTP.
CrushFTP
CrushFTP 11.5.2 a été installé avec succès et a accepté des connexions SFTP avec authentification par clé publique Ed25519, mais il n’a pas pu être inclus dans la comparaison de performances. Chaque téléversement a échoué avec une réponse serveur 550 openFile error:Denied! malgré des permissions de système de fichiers en écriture et une configuration de répertoire personnel utilisateur valide.
Figure 5 : exemple de connexion CrushFTP.
L’enquête a désigné l’état d’enregistrement installé comme cause probable, car les écritures étaient refusées globalement plutôt qu’à un chemin spécifique, mais nous ne l’avons pas vérifié de manière concluante. Nous n’avons pas tenté de contourner ni de fabriquer une licence.
Une licence d’essai ou de production valide est nécessaire avant que CrushFTP puisse être testé sur la même base que les autres serveurs ; nous ne pouvons donc tirer aucune conclusion de performance de cette exécution.
Figure 6 : interface web CrushFTP.
Méthodologie du benchmark des logiciels serveur SFTP
Objectif du test
Le benchmark compare le comportement côté serveur des implémentations SFTP dans des conditions contrôlées. Nous avons contraint ou isolé le stockage, la latence réseau, le débit client, le CPU disponible et la mémoire dans la mesure du possible afin que les différences entre les implémentations serveur restent visibles.
Cela rend délibérément le benchmark plus étroit qu’un test de transfert de production de bout en bout. En particulier, le bouclage local et le stockage adossé à la mémoire visaient à exposer les coûts de traitement de protocole, de chiffrement, de concurrence, d’architecture de processus et de gestion des connexions, plutôt que les performances du WAN ou du système de stockage.
Environnement de test
La séparation des affinités CPU client et serveur a réduit la contention directe du CPU entre le générateur de charge et le serveur. La limite de mémoire de 6 Go a fourni une limite cohérente pour le test de sessions concurrentes et a rendu visible le coût des conceptions basées sur un processus par connexion. Le tmpfs a éliminé le débit disque normal de la plupart des tests, tandis que le bouclage local a éliminé la variabilité du réseau physique.
Avant de tester les implémentations SFTP, nous avons mesuré indépendamment les plafonds approximatifs de l’hôte. AES-128-GCM a atteint 2 737 Mo/s, ChaCha20-Poly1305 1 430 Mo/s, les écritures de stockage séquentielles 2 687 Mo/s, les écritures aléatoires environ 263 000 IOPS et le réseau en bouclage local 1 889 Mo/s. Les résultats SFTP nettement inférieurs à ces valeurs peuvent donc être interprétés comme étant limités principalement par le chemin serveur et protocole plutôt que par ces sous-systèmes matériels individuels.
Implémentation du client
La commande sftp standard d’OpenSSH n’a pas été utilisée comme générateur de transfert principal car, dans cet environnement, son comportement mono-flux plafonnait à environ 90 Mo/s. À ce stade, le benchmark aurait mesuré une limitation du client plutôt que des différences entre serveurs.
Les tests ont plutôt utilisé un client Go personnalisé basé sur github.com/pkg/sftp. Il effectue des lectures et des écritures simultanées afin que le serveur devienne le facteur limitant du transfert. La taille des paquets SFTP est restée à 32 Ko, conformément aux valeurs par défaut normales utilisées par OpenSSH et pkg/sftp. Nous avons testé un réglage de 256 Ko pendant le développement, mais il a provoqué des échecs de connexions OpenSSH, nous ne l’avons donc pas utilisé.
T1 : débit mono-flux
T1 a mesuré le chemin de transfert de base des fichiers volumineux. Nous avons téléversé un seul fichier de 3 Go puis l’avons téléchargé, en enregistrant chaque direction indépendamment. Nous avons répété chaque mesure trois fois et conservé le résultat médian. Les caches du système de fichiers ont été vidés entre les répétitions.
Ce test n’avait pas pour but d’estimer le débit WAN réel. Avec le client et le serveur sur la même machine, il offre une vue contrôlée de la rapidité avec laquelle chaque serveur peut traiter un flux SFTP soutenu lorsque le réseau et, pour la plupart des implémentations, les limites des disques physiques ont été supprimées.
T1b : comparaison des chiffrements
T1b a répété la charge de téléchargement en forçant soit AES-128-GCM, soit ChaCha20-Poly1305 côté client. Cela a mis en évidence des différences de prise en charge des chiffrements et dans la manière dont chaque implémentation interagit avec les capacités cryptographiques du CPU hôte.
Nous avons enregistré les chiffrements non pris en charge ou les transferts échoués comme résultats manquants. L’hôte prend en charge l’accélération AES, de sorte que l’environnement de test favorise naturellement les implémentations AES-GCM efficaces, mais les résultats sont restés dépendants de l’implémentation.
T2 : scalabilité des flux parallèles
T2 a mesuré l’évolution du débit agrégé lorsque la même charge de travail était répartie entre un, deux et quatre flux simultanés. Le volume total de données transférées est resté fixé à 3 Go ; l’augmentation du nombre de flux modifiait donc la concurrence.
Le rapport entre quatre flux et un flux a été utilisé comme principal indicateur de scalabilité. Un résultat proche de un suggère que des connexions supplémentaires n’augmentent guère le débit, tandis qu’un rapport plus élevé indique que le serveur peut utiliser une capacité d’exécution supplémentaire sous charge parallèle. Comme la charge utile totale était fixe, le test met l’accent sur la concurrence et l’utilisation du CPU plutôt que de récompenser une charge de travail plus importante.
T3 : charge de petits fichiers
Les transferts séquentiels volumineux ne représentent pas les charges dominées par des opérations de système de fichiers et de protocole. T3 a donc téléversé 20 000 fichiers de 4 Ko chacun et a mesuré le nombre de fichiers traités par seconde.
À cette taille, la bande passante de transfert en masse n’est pas le principal coût. Chaque fichier nécessite une séquence d’opérations SFTP et de travaux sur les métadonnées du système de fichiers, ce qui rend le test sensible aux surcharges d’ouverture, de création, de fermeture et de traitement des requêtes. Il complète T1 plutôt que de servir d’autre mesure de débit.
T4 : surcharge de connexion et d’authentification
T4 a exécuté 500 sessions séquentielles. Chaque itération a établi une connexion, s’est authentifiée à l’aide d’une clé publique et s’est déconnectée sans exécuter de transfert soutenu.
Nous avons enregistré la latence de connexion sous forme de valeurs p50, p95 et p99, ainsi que le nombre de connexions terminées par seconde. Cela isole l’établissement de session SSH/SFTP et rend visibles les différences architecturales, y compris le coût supplémentaire de gestion des processus associé aux serveurs qui créent un processus pour chaque connexion.
Nous avons testé l’authentification par clé publique. Nous avons laissé de côté les chemins d’authentification par mot de passe, clavier interactif, certificat, GSSAPI/Kerberos et multi-facteur dans le benchmark actuel ; T4 ne doit donc pas être généralisé à ces mécanismes d’authentification.
T5 : sessions concurrentes et évolution de la mémoire
T5 a augmenté progressivement le nombre de sessions simultanées de 50 vers 500 et a enregistré à la fois le nombre de connexions durables le plus élevé et la mémoire résidente consommée par session. Tous les serveurs ont fonctionné sous la même limite de mémoire de 6 Go.
Ce test a été particulièrement utile pour distinguer les architectures de serveur. Les implémentations dérivées d’OpenSSH et d’autres implémentations de type processus par connexion créent une surcharge de processus par session substantielle. En revanche, les implémentations pilotées par événements, basées sur des goroutines ou à threads peuvent partager considérablement plus d’état entre les connexions. Lorsqu’un serveur échouait avant d’atteindre le sommet de la montée en charge, le point d’échec était conservé comme partie du résultat, et non comme une extrapolation d’une capacité supérieure.
Le plafond de 500 sessions est une limite de cet environnement de test. Il ne s’agit pas d’une affirmation concernant la capacité maximale des serveurs qui l’ont atteint. Mesurer leur limite supérieure réelle nécessiterait un hôte plus grand et une montée en charge des connexions nettement plus élevée.
T6 : efficacité des ressources
T6 a mesuré l’utilisation du CPU et de la mémoire pendant qu’un transfert continu était actif. L’utilisation du CPU et la RSS ont été échantillonnées sur l’ensemble de l’arborescence des processus du serveur toutes les 0,5 secondes, plutôt que de surveiller uniquement le processus parent.
L’efficacité du CPU a été normalisée en pourcentage de CPU par Gbit/s de débit atteint. Cela fournit un contexte : une faible consommation de CPU est utile si le serveur transfère également des données à un débit significatif.
T7 : démarrage à froid
T7 a mesuré le temps écoulé entre le démarrage du processus serveur et l’acceptation de sa première connexion. Cela capture une surcharge de démarrage largement sans importance pour les démons de longue durée, mais qui peut compter pour les environnements de test jetables, les conteneurs, les services éphémères et les flux de travail de déploiement automatisés.
La mesure expose également des différences d’exécution qui sont pour la plupart absentes une fois qu’un processus est chaud, en particulier entre les petits démons natifs et les applications qui doivent initialiser une JVM ou un environnement d’exécution basé sur Python avant d’accepter des connexions.
Interprétation des résultats
Les valeurs manquantes indiquent soit une fonctionnalité non prise en charge, soit une mesure que nous n’avons pas pu terminer ; nous n’avons pas déduit de valeurs de remplacement.
L’environnement de bouclage local est particulièrement important lors de l’interprétation de T1 et T2. Les classements relatifs et les comportements de scalabilité sont utiles sur cet hôte contrôlé, mais ne traitez pas les chiffres absolus en Mo/s comme des prédictions pour un réseau réel. La latence, la perte de paquets, le produit bande passante-délai, le stockage distant et le comportement du client peuvent modifier sensiblement le résultat.
OpenSSH nécessite également une réserve spécifique : son compte de benchmark écrivait dans un répertoire personnel adossé au disque plutôt que dans le tmpfs utilisé par les autres implémentations. Ses chiffres absolus T1 et T2 ne sont donc pas strictement comparables à ceux des autres serveurs, même si les mesures restent utiles pour comprendre son comportement dans la configuration testée.
Solutions de transfert de fichiers géré pour SFTP
Si vous souhaitez davantage de fonctionnalités d’administration et une utilisation plus simple, vous pouvez également choisir des solutions de transfert de fichiers géré :
JSCAPE
JSCAPE fournit une plateforme de transfert de fichiers géré dotée de capacités de serveur SFTP, permettant des échanges de fichiers sécurisés et chiffrés entre réseaux. Elle prend également en charge le protocole OFTP2 pour la transmission sécurisée de données dans l’automobile et d’autres secteurs.
Choisir JSCAPE comme SFTPStonebranch
La fonctionnalité Secure File Transfer Protocol (SFTP) de Stonebranch fait partie de sa solution Managed File Transfer (MFT) et assure des transferts de données sécurisés, fiables et automatisés. Prenant en charge divers environnements informatiques, notamment les mainframes, les plateformes cloud et les systèmes hybrides, la fonctionnalité logicielle serveur SFTP garantit le chiffrement et la conformité aux normes de sécurité du secteur, ce qui la rend adaptée aux échanges de fichiers internes comme externes.
Découvrir StonebranchDiplomat MFT par Coviant Software
Diplomat MFT par Coviant Software est une plateforme de transfert de fichiers géré auto-hébergée conçue autour de SFTP. Elle héberge son propre serveur SFTP pour les partenaires entrants, se connecte aux serveurs SFTP partenaires et applique un chiffrement OpenPGP à chaque transaction.
La passerelle Edge Gateway se trouve dans la DMZ et accepte les connexions des partenaires, tandis que le serveur Diplomat qui exécute les workflows reste sur le réseau interne. Aucun identifiant ni fichier n’est stocké en périphérie, et le pare-feu interne n’a besoin d’aucune règle entrante. Elle est principalement déployée dans des secteurs réglementés tels que la santé, les services financiers, le gouvernement, le commerce de détail et l’industrie manufacturière.
La version 9.5.1 (octobre 2026) ajoute le contrôle des algorithmes SSH côté serveur comme côté partenaire. Les administrateurs peuvent activer, désactiver et réordonner les algorithmes d’échange de clés, de signature, de chiffrement, HMAC et de compression, et les algorithmes obsolètes sont désactivés par défaut.
Les clients SFTP entrants sont vérifiés par rapport à la réputation IP Threat Intelligence. Une nouvelle liste de dérogation admet les partenaires vérifiés sur des adresses cloud partagées sans désactiver le blocage. L’option TOTP ajoutée pour les utilisateurs du portail Web Transfer dans la même version ne s’applique pas à SFTP, qui repose toujours sur l’authentification par clé et les règles d’accès IP.
Découvrir Diplomat MFTCerberus FTP Server
Cerberus FTP Server est une solution basée sur Windows conçue pour des installations sur site ou dans le cloud. Elle offre l’intégration AD/LDAP, l’authentification unique (SSO), les transferts via client web et la conformité aux normes de chiffrement telles que FIPS 140-2. Les fonctionnalités essentielles incluent l’analyse automatisée, l’automatisation pilotée par événements et la prise en charge de la conformité HIPAA.
Choisir CerberusGoAnywhere MFT
GoAnywhere MFT propose une solution SFTP sécurisée pour les transferts de fichiers, en mettant l’accent sur le chiffrement et la conformité. Il vise à garantir l’intégrité et la confidentialité des données, avec des fonctionnalités de gestion des clés, d’authentification et de journalisation, destinées aux organisations qui privilégient les échanges de données sécurisés et réglementés.
Lectures complémentaires
- Top 10 des solutions de transfert de fichiers géré (MFT)
- Top 6 des solutions logicielles AS2 : sélections issues de 400+ avis
- Axway Managed File Transfer : points clés à prendre en compte
Ajouter comme source préféréeCitez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Ermut, Sıla},
title = {{Top 8 des logiciels serveur SFTP}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/sftp-server-software}},
note = {AIMultiple. Consulté le 27 octobre 2026}
}Résultats et horodatages de 72 points de données. Téléchargez les données de synthèse présentées dans les graphiques et les tableaux de cet article sous forme de fichier ZIP contenant 10 fichiers CSV et un README.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Journal des modifications
11 mises à jourAjout d'une section méthodologie de benchmark couvrant huit serveurs SFTP.
Remplacement de la section Files.com par une nouvelle section sur Diplomat MFT de Coviant Software.
Stonebranch et Files.com ont été ajoutés à la liste des solutions de serveur SFTP.
Le travail de Cem chez AIMultiple a été cité par des publications mondiales de premier plan, notamment Business Insider, Forbes, Morning Brew et Washington Post, par des entreprises mondiales comme Deloitte et HPE, par des ONG comme World Economic Forum et par des organisations supranationales comme European Commission. [1], [2], [3], [4], [5]
Tout au long de sa carrière, Cem a été consultant en technologies, acheteur de technologies et entrepreneur technologique. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la digitalisation.
Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité du PDG. Il a également dirigé la croissance commerciale de l'entreprise de technologie profonde Hypatos, qui a atteint un revenu récurrent annuel à 7 chiffres et une valorisation à 9 chiffres, passant de 0 à ce résultat en deux ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.
Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de Bogazici University en tant qu'ingénieur informatique et titulaire d'un MBA de la Columbia Business School.
Elle a précédemment travaillé comme recruteuse dans des cabinets de gestion de projet et de conseil. Sıla est titulaire d’un master en psychologie sociale et d’une licence en relations internationales.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.