Marché

Marché des transferts de fichiers

En dépit des opinions de différents experts IT annonçant depuis des années l’effondrement imminent du marché des logiciels de  transfert de fichiers dans directions de services informatique, on observe que le nombre des transferts augmente régulièrement. En même temps, des besoins de nouvelles fonctionnalités apparaissent et deviennent indispensables. Les demandes nouvelles qui nous arrivent de plus en plus souvent concernent des possibilités d’envoi non seulement des fichiers mais aussi des objets sérialisables stockés  dans le Cloud ou dans les FS  locaux donc des échanges InputStream -> OutputStream , de prise en compte de conversions de code de données unicode, etc. … Ca signifie que le marché de transferts de fichiers (et pas seulement) est toujours là, il évolue et il accroît mais les éditeurs des logiciels de ce type de logiciels doivent rester vigilants pour pouvoir répondre aux nouveaux besoins tout en gardant la compatibilité avec des solutions utilisées par des nombreux partenaires d’échanges.    

Les protocoles

Dans le paysage actuel des standards et protocoles de transferts des fichiers on peut distinguer deux grands groupes des protocoles qui se différencient par leurs origines et  leurs finalités. Évidemment tous ces standards ont les capacités de transférer des fichiers mais quand pour certains cette fonctionnalité est la finalité pour elle même quand pour d’ autres d’arriver à transférer un fichier ne suffit pas. La conscience des besoins supplémentaires n’est pas innée. Elle est propre aux responsables de services des entreprises où la gestion des très forts flux des transferts se heurtent aux besoins de leurs services de production informatique ou à ceux qui sont très soucieux d’assurer la sécurité de leurs flux allant au-delà de la sécurisation de transport par utilisation de tunnels TLS ou SSH. 

Les protocoles “classiques” de transfert des fichiers comme FTP(S), SFTP datent déjà. L’origine communautaire de ces protocoles a fait que leurs finalités étaient limitées à leur finalité première; –  le transfert des fichiers. Des évolutions apportées par la communauté (comme, par exemple, l’ajout de la commande SITE dans FTP) ouvrent des nouvelles possibilités mais ne suffisent pas à changer la nature de ces protocoles. Leur finalité reste toujours la même. D’autre part, les propositions des évolutions de ces protocoles arrivent et sont discutées en continu mais il ne peut pas être de même avec leurs implémentations dans des logiciels pour que les nouveautés puissent être mises en pratique.     

La conscience des besoins beaucoup plus complexes était la base de définition d’un protocole beaucoup plus évolué comme le protocole PeSIT (spécifications disponibles à www.pesit.org ). Un groupe de travail des experts de transferts des fichiers, de la production informatique et des spécialistes de télécom d’un grand groupement d’établissements financiers s’est penché sur le sujet et il a élaboré le protocole qui permet non seulement transférer des fichiers entre différents systèmes mais d’organiser le service de transfert des fichiers en prenant en compte l’identification et de classification de chaque transfert de bout en bout, de gérer les transferts en mode “store and forward” avec leur suivi, d’effectuer des acquittements applicatifs de réceptions de fichiers, de gérer des priorités de transferts et organiser le contrôle de flux au delà de contrôle de flux au niveau transport. Des échanges de messages,  des champs d’utilisateurs et classification des flux par l’identification d’application permettent de mieux ancrer chaque transfert dans des applications business exploratrices des données échangées. Ces besoins sont évidents pour des responsables de services des transferts de fichiers dans des institutions financières, d’assurance ou de grande distribution et échappent à la conscience de responsables de services IT ayant en charge  quelques centaines de transferts par jour. Ils n’ont jamais eu à assurer une reprise de transferts des dizaines des milliers de fichiers en attente sur leur propre serveur en faisant face aux flux incessant de demandes de transferts d’extérieur ce qui arrive souvent après un incident de réseaux. Il y a des services qui doivent avoir la capacité de transférer des millions de fichiers par jour et les faire sous des fortes contraintes de temps de leurs exploitation par le service de production. 

Un autre protocole très intéressant était également conçu pour les besoins d’un établissement financier pour assurer une sécurité sans faille des transactions de clients de la banque. Le transfert de fichier est une ou plutôt deux des multiples fonctionnalités du protocole EBICS (spécifications disponibles à www.ebics.org) donc on ne peut pas même dire que c’est un protocole de transfert de fichier. C’est un protocole qui est porté par des flux HTTPS où chaque requête/réponse HTTPS constitue une transaction EBICS authentifiée, chiffrée et signée par des certificats appropriés. Ces certificats sont  échangés seulement une fois lors de la phase de connexion EBICS qui a lieu lors d’ouverture du compte ou lors de renouvellement/ changement de certificat. Le fait que les clés publiques ne circulent pas sur le réseau est un avantage indéniable du point de vue de la sécurité. Pour sa facilité de mise en œuvre (c’est toujours que le flux HTTPS qu’il faut faire passer par toutes les DMZ de réseau) il est utilisé pour assurer le transfert des fichiers où la sécurité des données et l’authentification forte des protagonistes sont vitaux.   

Notre approche

Notre très riche expérience dans le domaine de transfert de fichiers aussi bien côté l’architecture et développement de produits que côté l’organisation de services de transfert de fichiers et gestion des crises en production très intense nous a fait comprendre l’impact de choix de protocoles utilisés et de l’infrastructure de leur exploitation sur la productivité de services de transfert de fichiers d’envergure. Ces choix qui doivent être fait au niveau d’entité centrale des échanges souvent imposent l’utilisation du même protocole par des clients ou des entités périphériques. Ils peuvent être dictés par l’efficacité et capacités de gestion de service mais aussi par des coût d’achat et de la maintenance de la solution centrale et disponibilités et prix des solutions périphériques. Côté central les solutions bas prix basées sur l’utilisation de FTP ou de SFTP pour des échanges de masse sont acceptées en dépit des baisses de productivité car des utilisateurs périphériques peuvent être équipés par des solutions freeware largement disponibles. 

Ce n’est pas encore le cas du protocole PeSIT qui de loin est le protocole le mieux approprié pour organiser le vrai service de transfert de fichiers de masse. Notre but est de fournir des connecteurs de protocoles publiques en commençant par PeSIT pour rendre son implémentation plus facile pour des éditeurs, intégrateurs, grands comptes et autres utilisateurs qui hésitent à l’implémenter. PeSIT Client Léger, pour l’instant encore payant, est une solution indépendante visant les besoins de la population dite périphérique. 

La solution MFT X-Protocols de notre partenaire Evoleen.byGecko intègre déjà nos connecteurs PeSIT pour tirer la meilleure partie de nos logiciels. Toutes ces offres ont pour but de promouvoir le protocole PeSIT qui, nous croyant très fortement, méritent d’être mieux connu que c’est le cas aujourd’hui. Dans le cadre de cette promotion nous avons publié la dernière spécification du protocole sur le site www.pesit.org pour qu’il garde sa nature d’être un protocole publique comme il a toujours été. Nous planifions d’ouvrir également un nouveau site www.pesit.net qui permettra aux utilisateurs de ce protocole, tous les produits du marché confondus,  d’émettre des propositions d’évolution du protocole, de suivre leurs acceptation et leurs implémentations dans des produits exploités.  

Nous avons la même approche vis-à-vis du protocole EBICS sauf que dans ce cas là le protocole est très bien connu et maintenu par des organisations appropriées. 

Pour compléter notre offre nous allons proposer des connecteurs présentant des interfaces similaires pour d’autres protocoles publiques comme FTP(S), SFTP, HTTP, etc. …

N’hésitez pas à prendre contact pour avoir plus d’informations. Nous restons à votre service.