Top 8 des logiciels de 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 travail sur 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 mieux adaptée à l'entreprise, envisagez les solutions MFT.
Résultats du benchmark des logiciels de serveur SFTP
Performances de transfert
Coût opérationnel
Remarque : des scores inférieurs 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, les backends S3, Google Cloud Storage et Azure Blob, et inclut des fonctionnalités opérationnelles telles que des quotas, des règles d'événements, l'authentification à deux facteurs et des 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 pendant le 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 handshake la plus faible du groupe testé (25 ms en p50, soit moins de la moitié du serveur suivant le plus rapide) et une faible consommation de mémoire par session (0.091 Mo, soit environ 145× de moins qu'OpenSSH). Ses performances multi-flux ont également bien évolué sans adopter de modèle processus-par-connexion. Cette combinaison en a fait le meilleur résultat généraliste de ce benchmark.
Figure 2 : Tableau de bord d'administration SFTPGo.
HPN-SSH
HPN-SSH est un dérivé d'OpenSSH orienté 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é. À part ce conflit, il s'est comporté de manière similaire à OpenSSH.
Il a obtenu le meilleur résultat de téléversement en flux unique (167.4 Mo/s, bien que MINA à 166.9 Mo/s et SFTPGo à 165.3 Mo/s aient terminé à moins de 1.3 %) et le démarrage de processus le plus rapide du benchmark (0.88 s), mais a hérité du modèle de mémoire de type processus-par-connexion d'OpenSSH. Sous la limite de mémoire imposée de 6 Go, il a échoué lorsque le test de sessions simultanées a atteint 300 connexions.
Le benchmark a été exécuté entièrement en boucle locale, de sorte qu'il ne teste 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 que visent ses modifications à fenêtres élargies. Son avantage WAN reste donc en dehors du périmètre de ces résultats.
Apache MINA SSHD
Apache MINA SSHD se distingue 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 un JAR autonome avec Maven. L'application contrôle les clés d'hôte, l'authentification, la prise en charge de SFTP et la configuration du chiffrement, plutôt qu'un fichier de configuration de serveur classique.
Cela a entraîné 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 exigé une dépendance supplémentaire. L'authentificateur standard par clés autorisées a également rejeté le fichier de clé du benchmark en raison de ses vérifications de permissions, de sorte que le serveur de test a utilisé un chemin de comparaison de clé personnalisé.
Une fois en cours d'exécution, MINA a toutefois bien performé : il a produit le meilleur résultat de téléchargement (172.4 Mo/s), une faible consommation de mémoire par session, et la deuxième meilleure efficacité CPU mesurée lors du test d'efficacité des ressources (132.8 % par Gbps, derrière les 119.4 % d'OpenSSH). Le principal coût d'exécution a été le temps de démarrage de la JVM (3.39 s jusqu'à la première connexion). Il constitue donc un composant d'implémentation convaincant pour les applications nécessitant un point de terminaison SFTP embarqué, mais pas un substitut direct à un produit SFTP orienté administrateur.
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 compte OpenSSH et de sshd_config.
Les problèmes opérationnels étaient des problèmes familiers d'OpenSSH, et non une instabilité du sous-système SFTP lui-même. Des propriétés ou permissions incorrectes ont déclenché StrictModes, et le service systemd HPN-SSH a initialement occupé le port du benchmark. Après suppression de ce conflit, le serveur a fonctionné de manière cohérente.
OpenSSH a mieux géré la charge de travail sur petits fichiers 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 le plus bas par unité de débit à 119.4 % par Gbps, mais son architecture de type processus-par-connexion a utilisé comparativement plus de mémoire par session active (13.283 Mo).
Ses résultats de débit pour les gros fichiers nécessitent une précision supplémentaire : cette instance de benchmark a écrit dans le répertoire personnel de l'utilisateur système sur le disque, tandis que les autres serveurs testés utilisaient tmpfs. Par conséquent, ses valeurs de débit absolues T1 et T2 et le chiffre de CPU par Gbps normalisé par rapport à elles ne doivent pas être considérés comme directement équivalents au reste du groupe.
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 pendant ce benchmark. mod_sftp a dû être chargé explicitement, la politique d'écrasement par défaut bloquait les envois, 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 handshake la plus élevée parmi les serveurs mesurés (423 ms en p50, 3.6× le suivant le plus lent). L'exception a été la mise à l'échelle des flux parallèles : le débit agrégé a augmenté considérablement à mesure que la concurrence augmentait, atteignant 3.51× le flux unique à quatre flux, ce qui a donné à ProFTPD le ratio de mise à l'échelle le plus élevé de ce test. Ces résultats ont plus de sens 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é construite sur Python et Twisted. Elle est fournie avec son propre environnement d'exécution Python et utilise un format de configuration lisible basé sur INI. 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 exigeait 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 d'exécution différait de ce que la logique de surveillance initiale attendait.
Les performances reflétaient des priorités différentes de celles des serveurs orientés débit : SFTPPlus a affiché une consommation de 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 en p50), mais des envois de gros fichiers relativement lents (41.8 Mo/s), un traitement des petits fichiers (244 fichiers par seconde) et un démarrage de processus (7.49 s, soit 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 des domaines et des utilisateurs, l'interface web servant de principale voie de gestion ; une configuration XML et une interface de 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 en Lua échouait de manière répétée 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 tant que nous ne l'avions pas ajouté manuellement.
Les performances mesurées étaient nettement asymétriques : les téléchargements étaient considérablement plus rapides que les envois (129.7 Mo/s contre 34 Mo/s, soit un écart de 3.8× et le chiffre d'envoi le plus bas 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 de CPU par rapport au débit atteint était élevée (433.7 % par Gbps, soit près du 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 de type threads plutôt que processus-par-connexion.
Figure 4 : Éditeur d'utilisateur Wing FTP.
CrushFTP
CrushFTP 11.5.2 a été installé avec succès et acceptait les connexions SFTP avec l'authentification par clé publique Ed25519, mais il n'a pas pu être inclus dans la comparaison des performances. Chaque envoi échouait avec une réponse serveur 550 openFile error:Denied! malgré des permissions de système de fichiers accessibles en écriture et une configuration valide du répertoire personnel de l'utilisateur.
Figure 5 : Exemple de connexion CrushFTP.
L'enquête a indiqué 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 de licence.
Une licence d'essai ou de production valide est requise avant que CrushFTP puisse être testé sur la même base que les autres serveurs, de sorte que nous ne pouvons tirer aucune conclusion de performance de cette exécution.
Figure 6 : Interface web CrushFTP.
Méthodologie du benchmark des logiciels de 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 lorsque cela était possible afin que les différences entre les implémentations de 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, la boucle locale et le stockage adossé à la mémoire visaient à exposer le traitement du protocole, le chiffrement, la concurrence, l'architecture des processus et les coûts de gestion des connexions plutôt que les performances WAN ou du système de stockage.
Environnement de test
La séparation de l'affinité CPU du client et du serveur a réduit la contention directe du CPU entre le générateur de charge et le serveur. Le plafond de mémoire de 6 Go a fourni une limite cohérente pour le test de sessions simultanées et a rendu visible le coût des conceptions de type processus-par-connexion. Le tmpfs a supprimé le débit disque normal de la plupart des tests, tandis que la boucle locale a supprimé 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 séquentielles du stockage 2 687 Mo/s, les écritures aléatoires environ 263 000 IOPS et la mise en réseau en boucle locale 1 889 Mo/s. Les résultats SFTP nettement inférieurs à ces valeurs peuvent donc être interprétés comme limités principalement par le serveur et le chemin protocolaire 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 principal générateur de transfert car, dans cet environnement, son comportement en flux unique plafonnait à environ 90 Mo/s. À ce stade, le benchmark aurait mesuré une limitation du client plutôt que des différences entre les serveurs.
À la place, les tests ont 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 côté limitant du transfert. La taille des paquets SFTP est restée à 32 Ko, ce qui correspond aux valeurs par défaut normales utilisées par OpenSSH et pkg/sftp. Nous avons testé un paramètre de 256 Ko pendant le développement, mais cela a entraîné des échecs de connexions OpenSSH, donc nous ne l'avons pas utilisé.
T1 : débit en flux unique
T1 a mesuré le chemin de transfert de base des gros fichiers. Nous avons envoyé 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 avons retenu le résultat médian. Les caches du système de fichiers ont été vidés entre les répétitions.
Ce test n'était pas destiné à estimer le débit WAN réel. Avec le client et le serveur sur la même machine, il fournit 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 du disque physique ont été supprimées.
T1b : comparaison des chiffrements
T1b a répété la charge de travail de téléchargement en forçant soit AES-128-GCM, soit ChaCha20-Poly1305 du côté client. Cela a exposé 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 de l'hôte.
Nous avons enregistré les chiffrements non pris en charge ou les transferts échoués comme des 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 restaient dépendants de l'implémentation.
T2 : mise à l'échelle 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 restait 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 mise à l'échelle. Un résultat proche de un suggère que des connexions supplémentaires n'augmentent que peu le débit, tandis qu'un rapport plus élevé indique que le serveur peut exploiter 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 travail sur petits fichiers
Les gros transferts séquentiels ne représentent pas les charges de travail dominées par les opérations du système de fichiers et du protocole. T3 a donc envoyé 20 000 fichiers de 4 Ko chacun et mesuré le nombre de fichiers terminés par seconde.
À cette taille, la bande passante de transfert en masse n'est pas le coût principal. Chaque fichier nécessite une séquence d'opérations SFTP et un travail de 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 de nouvelle mesure de débit.
T4 : surcharge de connexion et d'authentification
T4 a exécuté 500 sessions séquentielles. Chaque itération établissait une connexion, s'authentifiait à l'aide d'une clé publique, puis se déconnectait sans effectuer 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, notamment le coût supplémentaire de gestion des processus associé aux serveurs qui effectuent un fork pour chaque connexion.
Nous avons testé l'authentification par clé publique. Nous avons laissé les chemins d'authentification par mot de passe, interactive au clavier, par certificat, GSSAPI/Kerberos et multifacteur en dehors du benchmark actuel, de sorte que T4 ne doit pas être généralisé à ces mécanismes d'authentification.
T5 : sessions simultanées et évolution de la mémoire
T5 a augmenté progressivement le nombre de sessions simultanées de 50 à 500 et a enregistré à la fois le nombre maximal de connexions durables 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 de type processus-par-connexion créent une surcharge de processus substantielle par session. À l'inverse, les implémentations pilotées par événements, basées sur les goroutines ou multithreadées peuvent partager considérablement plus d'état entre les connexions. Lorsqu'un serveur échouait avant d'atteindre le sommet de la rampe, 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 terminé. Mesurer leur limite supérieure réelle nécessiterait un hôte plus grand et une rampe de 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 le processus parent.
L'efficacité du CPU a été normalisée en pourcentage de CPU par Gbps 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 rythme 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 la 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 à courte durée de vie 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 inféré de valeurs de remplacement.
L'environnement en boucle locale est particulièrement important lors de l'interprétation de T1 et T2. Les classements relatifs et le comportement de mise à l'échelle sont utiles sur cet hôte contrôlé, mais ne traitez pas les chiffres absolus en Mo/s comme des prévisions 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 précision particulière : 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 administratives et une utilisation plus facile, vous pouvez également choisir des solutions de transfert de fichiers géré :
JSCAPE
JSCAPE fournit une plateforme de transfert de fichiers géré avec des capacités de serveur SFTP, permettant des échanges de fichiers sécurisés et chiffrés sur les réseaux. Il 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 fournit 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é du logiciel 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 et externes.
Découvrir StonebranchDiplomat MFT par Coviant Software
Diplomat MFT par Coviant Software est une plateforme de transfert de fichiers géré sur site construite autour de SFTP comme couche de transport sécurisée principale, avec le chiffrement PGP comme capacité de premier ordre. Coviant Diplomat MFT est conçu pour les organisations des secteurs réglementés, telles que la santé, les services financiers, le gouvernement et la fabrication, qui ont besoin d'une automatisation des flux de travail sans code, d'outils de conformité intégrés et d'un modèle de déploiement stable et auto-hébergé.
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 une intégration AD/LDAP, SSO, des transferts par 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 fournit 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 : principaux éléments à 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 de serveur SFTP}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/sftp-server-software}},
note = {AIMultiple. Consulté le 20 Août 2026}
}Résultats et horodatages de 16 points de données. Téléchargez les données utilisées dans cet article sous forme de fichier ZIP contenant 2 fichiers CSV et un README.
Journal des modifications
11 mises à jour- 2026
Ajout 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.
- 2025
Supprimé Globalscape MFT et MOVEit Managed File Transfer de la liste des solutions analysées.
Supprimé MOVEit Managed File Transfer de la liste des logiciels de serveur SFTP.
Suppression de la Figure 1 et de la Figure de la section Cerberus.
Stonebranch a été ajouté à la section "Top 8 des logiciels de serveur SFTP en 2026".
- 2024
Ajout de JSCAPE, Cerberus FTP, MOVEit, GoAnywhere MFT, Files.com, Thru et SolarWinds SFTP/SCP Server à l'introduction.
Ajout d'un lien vers des solutions SFTP gratuites dans l'introduction.
Ajout de Cerberus FTP Server à la liste des meilleures solutions de serveur SFTP.
Ajout de JSCAPE à la liste des logiciels 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.