Choisir le mode de déploiement d’une plateforme de Managed File Transfer (MFT) engage à la fois la sécurité des échanges, la conformité réglementaire et l’organisation interne des équipes. Les deux options principales, SaaS et on premise, répondent à des logiques différentes : d’un côté une solution hébergée et exploitée par l’éditeur, de l’autre une installation maîtrisée par l’organisation sur sa propre infrastructure.
Réponse directe : Il n’existe pas de choix universel entre SaaS et on premise pour une plateforme MFT. L’arbitrage dépend du niveau de contrôle attendu sur les données, des exigences réglementaires applicables (RGPD, référentiels ANSSI, souveraineté), des ressources techniques internes disponibles et des délais de mise en œuvre. Un SaaS qualifié peut convenir à de nombreuses organisations ; l’on premise reste privilégié lorsque le contrôle complet de l’infrastructure est une exigence structurelle.
Cet article compare les deux modes point par point, en s’appuyant sur les repères officiels (ANSSI, CNIL) et sur les critères concrets d’arbitrage, pour aboutir à une grille de décision reliant profil d’organisation et déploiement recommandé.
SaaS et on premise : deux modes de déploiement d’une plateforme MFT
Avant de comparer les critères d’arbitrage, il est utile de poser précisément ce que recouvre chaque mode. Les deux approches reposent sur des logiques d’exploitation très différentes, avec des conséquences directes sur la répartition des responsabilités.
Le SaaS : une plateforme hébergée et exploitée par l’éditeur
Dans un déploiement SaaS (Software as a Service), la plateforme MFT est hébergée, maintenue et exploitée par l’éditeur. L’organisation cliente y accède via un abonnement, le plus souvent par navigateur ou via des connecteurs sécurisés. L’éditeur prend en charge l’infrastructure, les mises à jour, la supervision technique et la disponibilité du service, dans le cadre contractuel défini.
Pour une organisation souhaitant déployer une solution de transfert de fichiers sécurisé sans mobiliser d’équipe dédiée à l’exploitation d’une infrastructure, ce modèle réduit le temps de mise en production et transfère une partie de la charge opérationnelle vers le prestataire. En contrepartie, les données transitent et peuvent être stockées sur une infrastructure gérée par un tiers, ce qui déplace le périmètre de contrôle.
L’on premise : une installation sur l’infrastructure interne
Le mode on premise consiste à installer la plateforme MFT sur l’infrastructure de l’organisation : datacenter interne, cloud privé ou environnement hébergé mais exploité par les équipes internes. La maîtrise porte alors sur l’ensemble de la chaîne : serveurs, réseau, systèmes d’exploitation, chiffrement, sauvegardes, journaux d’accès.
Ce choix donne un contrôle complet sur la localisation des données et les paramètres de sécurité, mais implique une responsabilité pleine sur l’exploitation : mises à jour, correctifs, supervision, continuité d’activité et conformité restent à la charge des équipes internes ou d’un intégrateur mandaté.
Une répartition des responsabilités fondamentalement différente
La distinction centrale ne porte pas uniquement sur le lieu d’hébergement, mais sur la répartition des rôles. En SaaS, l’organisation reste responsable de traitement au sens du RGPD, mais s’appuie sur un sous-traitant pour l’exploitation technique. En on premise, elle conserve également la responsabilité opérationnelle complète. Certaines solutions, comme MFT Online, sont proposées dans les deux modes de déploiement, ce qui permet d’ajuster le choix au contexte sans changer d’outil.
Quels critères de sécurité et de conformité peser dans l’arbitrage ?
Les exigences réglementaires et de souveraineté sont souvent le premier filtre d’arbitrage. Elles conditionnent la liste des solutions acceptables avant même de considérer les critères économiques.
Responsable de traitement et sous-traitant : une répartition RGPD à formaliser
Dans les deux modes, l’organisation qui décide des finalités du traitement reste responsable de traitement. En SaaS, l’éditeur agit comme sous-traitant au sens de l’article 28 du RGPD. La CNIL rappelle les règles d’identification des rôles RGPD et précise que le responsable du traitement doit s’assurer que son sous-traitant offre toutes les garanties nécessaires, le contrat précisant concrètement la mise en œuvre du niveau de sécurité requis.
En on premise, la question du sous-traitant ne disparaît pas totalement : elle peut concerner l’hébergeur de l’infrastructure, l’infogérant ou l’éditeur chargé de la maintenance applicative. L’exercice d’identification des rôles reste donc indispensable.
Certifications d’hébergement et référentiels ANSSI
Pour les données les plus sensibles, les référentiels de l’Agence nationale de la sécurité des systèmes d’information (ANSSI) constituent un repère structurant. La FAQ ANSSI sur la qualification SecNumCloud précise que les offres SaaS, PaaS, IaaS et CaaS peuvent toutes être éligibles, que la qualification est valable 3 ans avec audits annuels de surveillance, et qu’elle s’applique à une offre de service précise, non au prestataire dans sa globalité.
Autrement dit, un éditeur peut proposer plusieurs offres dont une seule est qualifiée. La vérification doit donc porter sur l’offre exacte envisagée, et non sur une mention commerciale générique. En on premise, la question se déplace vers les certifications de l’infrastructure sous-jacente et de l’infogérant éventuel.
Localisation des données et souveraineté numérique
La localisation effective des données et la juridiction applicable à l’hébergeur sont des critères déterminants. Un enquête PwC France sur les arbitrages cloud en 2025 indique que des entreprises françaises adoptent un cloud souverain pour l’IA : 46 % des entreprises françaises adoptent un cloud souverain pour l’IA, contre 30 % en moyenne EMEA, la régulation étant citée comme principal défi par 48 % des entreprises françaises (PwC, 2025). Cette préoccupation s’applique largement aux plateformes de transfert de fichiers, qui manipulent par nature des données opérationnelles sensibles.
En SaaS, la souveraineté passe par le choix d’une offre hébergée dans une juridiction compatible avec les exigences internes, idéalement qualifiée pour les cas d’usage les plus sensibles. En on premise, la souveraineté est acquise par construction, sous réserve de maîtriser réellement la chaîne d’hébergement et d’infogérance.
Vigilance sur les offres « souveraines » : l’étiquette commerciale ne vaut pas qualification. La vérification doit porter sur l’offre précise, sa localisation, sa gouvernance et les éventuelles qualifications officielles obtenues.
Chiffrement et contrôle des clés
Le chiffrement des flux et des données au repos est attendu dans les deux modes. La différence porte sur le contrôle des clés : en on premise, l’organisation peut conserver la maîtrise complète des clés de chiffrement. En SaaS, cette maîtrise dépend de l’architecture proposée par l’éditeur (clés gérées par l’éditeur, par le client, ou en mode BYOK/HYOK). Ce point mérite une clarification contractuelle explicite.
Coûts, maîtrise opérationnelle et délais de mise en œuvre
Au-delà de la sécurité, les deux modes présentent des structures économiques et opérationnelles distinctes. Les comparer uniquement par le prix d’achat est trompeur : la bonne lecture passe par le coût total de possession (TCO) et la charge réelle sur les équipes.
Structure des coûts : abonnement récurrent ou investissement initial
Le SaaS repose sur un abonnement récurrent, généralement calculé selon le nombre d’utilisateurs, le volume d’échanges ou les connecteurs activés. L’infrastructure, les mises à jour et la supervision sont incluses dans le modèle. L’on premise suppose un investissement initial (licences, infrastructure, intégration) complété par des coûts récurrents internes : maintenance applicative, infogérance, correctifs de sécurité, sauvegardes, supervision.
Comparaison des postes de coût
Pour objectiver la comparaison, il est utile de ventiler les principaux postes dans un tableau synthétique. Les valeurs chiffrées dépendant des volumes, des profils d’organisation et des contrats, le tableau ci-dessous se concentre sur la nature des coûts et leur portée.
| Critère | SaaS | On premise |
|---|---|---|
| Modèle économique | Abonnement récurrent | Investissement initial + coûts récurrents internes |
| Infrastructure | Prise en charge par l’éditeur | À la charge de l’organisation |
| Mises à jour et correctifs | Appliqués par l’éditeur | À planifier en interne |
| Supervision 24/7 | Incluse selon contrat | À organiser en interne ou via infogérance |
| Contrôle des données | Partagé avec le sous-traitant | Complet |
| Délai de mise en production | Court (déploiement standardisé) | Plus long (installation, intégration, tests) |
Charge opérationnelle et compétences internes
En SaaS, la charge opérationnelle interne se concentre sur le pilotage fonctionnel : définition des règles d’échange, administration des utilisateurs, suivi de la conformité contractuelle. En on premise, s’y ajoutent la maintenance applicative, la gestion des correctifs de sécurité, la supervision technique et la planification des évolutions. Cette charge peut être internalisée ou confiée à un intégrateur, mais elle doit être budgétée.
Coûts cachés à anticiper
Chaque mode présente des coûts moins visibles qu’il convient d’intégrer dans l’évaluation.
SaaS et on premise : des coûts cachés spécifiques
- Dépassement de quotas (utilisateurs, volume, connecteurs)
- Options de sécurité ou de conformité facturées en supplément
- Coûts de réversibilité en cas de changement d’éditeur
- Intégrations spécifiques avec le SI existant
- Mises à jour majeures et migrations de version
- Renouvellement de l’infrastructure
- Astreinte et supervision 24/7
- Audits de sécurité et tests d’intrusion réguliers
Comment choisir selon votre contexte organisationnel ?
La comparaison critère par critère ne suffit pas : le bon choix dépend du profil réel de l’organisation. Trois dimensions structurent utilement la décision : la sensibilité des données échangées, les capacités techniques internes, et les délais attendus pour la mise en production.
Profils favorisant un déploiement SaaS
Le SaaS est généralement bien adapté aux organisations qui doivent déployer rapidement, disposent de ressources techniques internes limitées et acceptent de s’appuyer sur l’éditeur pour la conformité opérationnelle de l’infrastructure. C’est également une option pertinente lorsque les flux et volumes évoluent fortement, le modèle d’abonnement permettant d’ajuster les capacités sans réinvestissement lourd.
Pour les données sensibles, la question centrale devient la nature de l’offre : son hébergement, ses qualifications éventuelles, les engagements contractuels sur la localisation et le chiffrement, et la clarté des rôles RGPD.
Profils favorisant un déploiement on premise
L’on premise reste pertinent lorsque le contrôle complet de l’infrastructure est une exigence structurelle : secteurs régulés avec contraintes de souveraineté strictes, politiques internes imposant une maîtrise totale des clés de chiffrement, intégration profonde avec un SI largement internalisé. Il suppose cependant la capacité, interne ou via un partenaire, à exploiter la plateforme dans la durée.
Grille de décision à trois questions
- Sensibilité des données :
Si les données imposent une qualification officielle (type SecNumCloud) ou un contrôle complet des clés, prioriser une offre SaaS qualifiée adaptée ou un déploiement on premise.
- Capacités techniques internes :
Si les équipes internes ne peuvent pas assumer la maintenance applicative, la supervision et les mises à jour, le SaaS réduit significativement la charge.
- Délais attendus :
Si la mise en production doit intervenir rapidement, le SaaS est généralement plus court à déployer. Si le projet s’inscrit dans un plan pluriannuel avec intégration SI forte, l’on premise reste praticable.
Situations hybrides et critères de bascule
Certaines organisations combinent les deux approches : un déploiement on premise pour les flux les plus sensibles, un SaaS pour les échanges courants ou les filiales. Les critères de bascule peuvent être le type de données, la zone géographique, le niveau de criticité des flux ou la nature des partenaires externes. Cette approche hybride suppose une gouvernance claire pour éviter la fragmentation des usages et des contrôles.
Pour approfondir la logique de sécurité appliquée aux flux de fichiers, cette lecture sur sécuriser les transferts de fichiers propose un éclairage complémentaire sur les enjeux liés aux échanges en ligne.
FAQ : questions fréquentes sur le déploiement d’une solution MFT
Avant de trancher, plusieurs interrogations opérationnelles reviennent régulièrement. Les éléments ci-dessous constituent des repères généraux et ne se substituent pas à une analyse personnalisée, en particulier sur les aspects contractuels et réglementaires.
Peut-on migrer d’un mode de déploiement à l’autre par la suite ?
Oui, lorsque l’éditeur propose les deux modes avec un socle fonctionnel compatible. La migration suppose néanmoins un projet dédié : reprise des configurations, des règles d’échange, des connecteurs et des comptes utilisateurs, ainsi que la validation de la conformité dans le nouveau mode. Il est recommandé d’anticiper cette possibilité dès le choix initial.
Comment garantir la réversibilité et la portabilité des données en SaaS ?
La réversibilité se négocie contractuellement : formats d’export, délais de restitution, procédures de suppression après migration. Pour les flux et historiques, il convient de vérifier la portabilité des journaux d’audit, des règles de routage et des configurations techniques. Ces points doivent figurer explicitement dans le contrat et le plan de réversibilité.
Un SaaS MFT est-il compatible avec des données sensibles ?
Oui, à condition que l’offre précise soit adaptée au niveau de sensibilité : hébergement dans la juridiction attendue, qualifications officielles éventuelles (SecNumCloud, HDS selon le contexte), engagements sur le chiffrement et le contrôle des clés, clauses RGPD conformes à l’article 28. La vérification doit porter sur l’offre exacte, non sur une mention générale de l’éditeur.
Quel déploiement choisir avec des ressources techniques internes limitées ?
Le SaaS est généralement plus adapté dans ce cas : il réduit la charge opérationnelle liée à l’infrastructure, aux mises à jour et à la supervision. Si le choix d’un on premise est néanmoins requis, le recours à un intégrateur ou à une infogérance qualifiée doit être prévu dès le cadrage du projet.
Comment vérifier concrètement les modes de déploiement et certifications proposés ?
La vérification passe par la demande à l’éditeur de la fiche de son offre précise : mode(s) de déploiement, localisation d’hébergement, certifications et qualifications en vigueur, périmètre couvert, date de validité et conditions. Les référentiels officiels de l’ANSSI et les publications de la CNIL permettent de recouper ces informations.
Pour avancer concrètement, l’étape suivante consiste à documenter votre contexte selon la grille proposée (sensibilité, capacités, délais), puis à solliciter des éditeurs sur des offres précises et comparables. Vous pouvez demander une démonstration pour objectiver la comparaison sur vos propres cas d’usage.
Le choix entre SaaS et on premise pour une plateforme MFT ne se joue pas sur une préférence de principe, mais sur la cohérence entre contraintes de conformité, ressources internes et niveau de contrôle souhaité. En clarifiant ces trois dimensions avant d’ouvrir la comparaison fournisseurs, l’arbitrage devient un choix documenté plutôt qu’un pari.