Une nouvelle norme européenne impose aux entreprises de chiffrer les échanges bancaires entre les entreprises et les banques. Les entreprises ont jusqu'à septembre pour s'équiper et la facture va être salée.
- Le projet SEPA - http://www.sepafrance.fr/
- EBICS - http://www.ebics.org/
- Swift - http://www.swift.com/corporates/france.html
- IBM rachète Sterling Commerce - http://www.sterlingcommerce.com/about/about-us/IBM-Announcement.htm
Le marché est très juteux pour les banques et les éditeurs d'ERP et de logiciels de transmission d'ordres bancaires. IBM vient par exemple de racheter Sterling Commerce.
A partir d'une certaine taille, les entreprises transmettent par informatique aux banques leurs ordres de virement bancaires. Cela leur facilite le travail. Ce service était jusqu'à présent gratuit (hormis les frais de gestion des comptes). Il existait plusieurs logiciels propriétaires permettant de transmettre la liste des montants à virer, avec les dates de virement, les RIB des destinataires, etc.
Le format de fichiers bancaire va évoluer, le format CFONB va être progressivement remplacé par le format SEPA. La plupart des éditeurs proposent déjà des outils pour générer ces fichiers à partir des logiciels de comptabilité et des ERP, y compris certains logiciels libres.
Mais le plus urgent, c'est la coupure par France Telecom en septembre de la liaison Transpac, qui servait à transmettre ces fichiers. Les entreprises doivent souscrire en urgence auprès des banques un contrat mensuel pour accéder à leurs serveurs via internet. Les protocoles de transmission proposés sont EBICS (utilisé en Europe), Swiftnet (mondial) et FTPS.
Curieusement, les banques ne communiquent que sur les protocoles propriétaires EBICS et Swiftnet qui sont hors de prix (50 à 100 €/mois) et ne parlent pas du FTPS qui ne coûterait rien et qui est ouvert. Impossible d'avoir une des informations techniques et une offre basée sur FTPS. Un simple client FTP suffirait à donner l'ordre de virer les salaires, sans avoir à acheter un certificat et à louer mensuellement un accès au serveur de sa banque ? Ce serait trop beau. Si quelqu'un a déjà utilisé une solution économique, facile à utiliser et basée sur des outils libres, je suis intéressé pour connaître cette solution.
# EBICS
Posté par Batchyx . Évalué à 10.
En quoi EBICS n'est-t'il pas libre ? J'ai pu récupérer la spécification en moins de deux clics. Ça n'est que du webservice sur HTTPS/TLS, avec apparemment les xsd disponibles, toute la sémantique bien décrite comme il faut, et je n'ai pas réussi à trouver une quelconque mention d'une licence ou royalties à payer.
Ou c'est juste que les banques veulent faire payer alors que c'était gratuit avant ?
[^] # Re: EBICS
Posté par Zenitram (site web personnel) . Évalué à 10.
Wikiepedia : "EBICS est un protocole sur IP, utilisant des messages XML véhiculés par le standard HTTPS. EBICS utilise les standards RSA, AES et X.509 pour ses aspects cryptographiques."
http://www.ebics.org/index.php?id=30 pour les specs.
Je ne sais pas ce qu'il veut effectivement comme "plus libre"...
Quand à Transpac, je dirai... Enfin! Car l'auteur du journal parle de "hors de prix" en parlant de 100€/mois, mais euh... Une liaison Transpac, qu'est-ce que c'est alors? Surtout que ce n'est pas que X25 était pourri, mais il a fait son temps, il est temps d'arrêter. J'ai l'impression d'entendre ma grand-mère râler contre le remplacement du Minitel par Internet ("faut payer un abo Internet, faut un modem ADSL, faut un ordinateur, arghhhh c'était mieux avant on avait juste le minitel").
En plus, la proposition du journal est complètement délirante (FTPS est fait pour transférer des fichiers, par pour effectuer des transactions, on peut arrêter les délire de fichiers pour faire des transactions? Ca s'est fait pendant longtemps certes, mais de nos jours on a mieux)
Bref, j'ai l'impression que là où le système s'améliore, il y en a pour râler.
Bon, au final, c'est quoi les vrais arguments contre SEPA une fois les erreurs du journal virées?
[^] # Re: EBICS
Posté par Kerro . Évalué à 4.
En fait de transpac, c'est une bête connexion par modem. C'est relayé "au bout" par Transpac. Donc pas d'abonnement spécifique, sauf pour ceux qui n'ont plus l'utilité d'une ligne analogique.
Et de toutes manières ce n'est pas du tout facturé 100 € par mois le nouveau basar.
Mais comme l'indique Enzo Bricolo plus bas, les prestataires (banques et éditeurs) sont raides nuls sur ce coup. Encore un truc tout simple qui va mettre 5 ans à fonctionner sans passer par des manipulations pourries.
[^] # Re: EBICS
Posté par tagada . Évalué à -4.
Non, c'est juste du vécu avec les banques. Voir la réponse d'Enzo Bricolo plus bas. Le problème, c'est les banques qui imposent et font payer très cher l'accès à leur système et qui refusent l'utilisation de standards ouverts.
Merci de bien lire avant de répondre et de critiquer.
[^] # Re: EBICS
Posté par Zenitram (site web personnel) . Évalué à 7.
En quoi HTTPS / XML / RSA / AES ne sont pas ouverts? et EBICS? Comment j'arrive à avoir les specs en 2 clics? Bien lire le commentaire, et contre-argumenter si tu penses toujours que c'est fermé. car je t'ai juste démontré le contraire donc j'attend de ta part une contre-argumentation pour dire que c'est fermé.
Réponse très intéressante mais qui ne dit pas qu'ils refusent l'utilisation de standards ouverts. Le fait que ce soit centré européen n'en fait pas quelque chose de fermé.
Je te retourne le compliment. Surtout quand on balance une énormité "FTPS" dès le départ, qui en plsu d'être peu adapté ne répond qu'à une partie du besoin (tu n'as pas dit quel format de fichier tu veux, ben oui, FTPS ça transporte des fichiers, et après? Tu n'as pas dit en quoi ce serait moins cher qu'HTTPS non plus, ben oui HTTPS est la norme choisie pour la couche équivalente à FTPS, et j'ai du mal à voir la baisse de prix avec ta propsoition)
Se tromper, OK, ça se corrige, insister sur une erreur (en tous cas, tu n'as toujours pas expliqué en quoi c'était fermé) devient du mensonge. J'attends donc une explication puisque tu continues de dire que c'est fermé, c'est que tu as regardé et tu es capable de dire ce qu'il te manque et qui est caché.
[^] # Re: EBICS
Posté par Vador Dark (site web personnel) . Évalué à -2.
Non, tu as juste démontré que ça reposait sur des standards ouverts. C'est comme dire que le protocole de Windows Live Messenger est ouvert car il repose sur TCP/IP ouvert et documenté.
[^] # Re: EBICS
Posté par Zenitram (site web personnel) . Évalué à 4.
C'est si compliqué d'aller sur le site adéquat (je t'aide : http://www.ebics.org ) et de récupérer les specs? (je t'aide : http://www.ebics.org/index.php?id=30 ).
Ca a l'air plus compliqué que de FUDer pour le plaisir, ça devient un mensonge à partir d'un moment.
Ah, parait que ça a déjà été dit :
https://linuxfr.org/nodes/86690/comments/1249831
(premier commentaire du journal!)
[^] # Re: EBICS
Posté par tagada . Évalué à 1.
Des logiciels libres de transfert par FTPS, il y en a à la pelle. Mais il n'y a aucun logiciel libre de transfert multibancaire vers tous pays via les canaux EBICS. On est obligé de passer par les portails Web des banques (payants, en plus des abonnements aux canaux EBICS et de l'achat des certificats).
[^] # Re: EBICS
Posté par Zenitram (site web personnel) . Évalué à 3.
Est-ce qu'il y a quelque chose qui empêche techniquement la réalisation d'un logiciel libre de transfert multibancaire vers tous pays via les canaux EBICS?
- Oui : en quoi?
- Non : tu peux le faire, donc pas de problème, c'est ton choix, ton problème, code.
Et encore une fois, FTPS, c'est le transport, équivalent à HTTPS dans EBICS si j'ai bien compris, et tu as toujours l’achat de certificats à faire. Et des logiciels libres faisant HTTPS, il y en a à la pelle. Donc pareil, jusque que FTP(S) n'est pas du tout adapté au transactionnel, HTTPS est un bien meilleur choix, à moins que tu me démontre le contraire...
J'ai vraiment du mal à comprendre cette volonté de balancer un protocole inadapté pour la couche de transport... Et surtout de dire que FTPS ça remplace "tout", alors que ça rempalce que HTTPS de EBICS. Donc vous mettez quoi derrière votre FTPS? Le reste de la spec EBICS?
[^] # Re: EBICS
Posté par Dabowl_75 . Évalué à 1.
FTPS est fait pour transférer des fichiers, par pour effectuer des transactions, on peut arrêter les délire de fichiers pour faire des transactions? Ca s'est fait pendant longtemps certes, mais de nos jours on a mieux
ah les bons vieux moniteurs de transferts de fichiers cft qui, lorsqu'ils ne marchent pas, font planter les précompensations et ça couine dans les chaumières....
+1 pour arrêter les transactions au moyen de fichier
et d'ailleurs, ça se fait déjà pour les flux comme les mises en oppo..
ce qui coince c'est que les systèmes distribués veulent causer avec les systèmes centraux, les dinosaures ne savent pas faire grand chose d'autre que cft, interpel, pelican, j'en passe et des ronds de chapeaux
[^] # Re: EBICS
Posté par Zenitram (site web personnel) . Évalué à 3.
Salaud, j'ai pris 15 ans dans la gueule. J'ai mis le lien Wikipedia pour les moins de 30 ans ;-).
[^] # Re: EBICS
Posté par syj . Évalué à -1.
tu peux donner la réference car j'avais cherché rapidement pour ma part et je n'ai rien trouvé.
Enfin, je mettais surtout attacher à trouver la liste des codes SWIFT.
[^] # Re: EBICS
Posté par Batchyx . Évalué à 5.
tu clique sur le lien "EBICS" du nourjal, et il y a au moins trois liens pointant vers les specs, choisi celui que tu veux...
[^] # Re: EBICS
Posté par tagada . Évalué à 0.
En fait, je me demande si EBICS est vraiment nécessaire. Le CIC par exemple propose maintenant de transférer ses fichiers au format SEPA directement depuis leur interface Web de gestion des comptes (service Filbanque). Donc plus besoin d'installer un logiciel de communication EBICS, ni de lecteur de carte de cryptage USB ni de logiciel de lecture de la carte ni de certificat à acheter et à gérer etc.
On uploade le fichier depuis leur site et c'est tout.
[^] # Re: EBICS
Posté par Zenitram (site web personnel) . Évalué à 3.
Pour toi, c'est sans doute suffisant.
Pour une grosse entreprise, juste le code d'accès, c'est sans doute insuffisant comme sécurité.
C'est comme tout, la sécurité doit être adaptée au besoin.
[^] # Re: EBICS
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
EBICS/SEPA n'était pas obligatoire, mais il tente de normaliser.
On avait déjà EDIFACT, EDIFACT-SEC et EDIINT AS2, il suffiait de les faire évoluer.
Au delà du CIC, tu as les éditeurs comme SAGE qui propose aussi un mode en ligne qui fait les comms EBICS pour toi. Tu postes sur leur portail avec un bout de curl et 3 certificats et roule ma poule. J'espère pour eux qu'ils n'auront pas un épisode à la SONY PSN.
Quelques commentaires :
1. Pour cette méthode, il faut avoir accès au "web", c'est pas toujours le cas des back office bancaire (Architecture et Sécurité)
2. Il faut administrer cet accès et sécuriser le poste client qui fait les accès à la banque (Administration)
3. Ton fichier SEPA que tu postes à la main, j'espère que ce n'est pas le fichier des ordres de virement des salaires de ta boite. (Confidentialité)
4. Ca peut bien marcher pour du EBICS T, pour du TS je demande à voir. (Ergonomie)
Enzo Bricolo
# Coût != Libre/Ouvert
Posté par ckyl . Évalué à 3.
Pourquoi un FTPS ne couterait rien ?
[^] # Re: Coût != Libre/Ouvert
Posté par dj_ (site web personnel) . Évalué à -5.
Toutes les entreprises ont normalement un accès a internet, et donc du FTP ça ne leur coûte rien.
Bon ok les banques pourraient demander quelques € pour utiliser du FTPS mais pas autant
[^] # Re: Coût != Libre/Ouvert
Posté par Zenitram (site web personnel) . Évalué à 6.
Pourquoi FTP coûterait moins que EBICS? C'est balancé par deux personnes (l'auteur du journal, puis le commentaire) sans aucune démonstration.
Ce n'est pas le protocole qui est facturé, ou alors je n'ai pas vu le coût sur le site des spécifications.
[^] # Re: Coût != Libre/Ouvert
Posté par dj_ (site web personnel) . Évalué à 0.
Je disais ça car avec un protocole spécialisé ils pourraient dire qu'ils ont des développement spécifique a faire pour adapter les programmes.
Mais c'est vrais que même avec du FTPS y a du développement a faire.
Donc je m'auto moinse
# Bitcoins!
Posté par JoeltheLion (site web personnel) . Évalué à -7.
Moinsez-moi :) Mais sans rire, c'est exactement pour concurrencer ce genre de choses que les bitcoins ont été crées.
[^] # Re: Bitcoins!
Posté par ckyl . Évalué à 4.
En quoi bitcoin empêche des intermédiaires de se sucrer ? Les places de marchés pour bitcoin prennent déjà une commission (faut bien les financer). Des intermédiaires équivalents à ceux actuels apparaitrons dans l’économie bitcoin. Et il n'y a aucun raison qu'ils se comportent différemment qu'actuellement. Ce n'est qu'une monnaie comme les autres (sans entrer dans le débat).
[^] # Re: Bitcoins!
Posté par JoeltheLion (site web personnel) . Évalué à -1.
La concurrence libre et non faussée. N'importe qui peut démarrer un marché, c'est simple et libre. Contrairement au système bancaire.
Avec la différence que tu n'as pas besoin d'intermédiaire pour l'envoyer aux quatre coins du monde.
[^] # Re: Bitcoins!
Posté par ckyl . Évalué à 3. Dernière modification le 04 juillet 2011 à 21:09.
Comme partout. Si ça devient sérieux tu auras aussi à te soumettre aux réglementations.
Par ailleurs qu'est ce qui t'empêche d'ouvrir un dark pool actuellement ? Où une banque qui aurait des pratiques que tu juges correctes ?
Envoyer la monnaie d'un point à un autre c'est uniquement une des nombreux besoins. Les intermédiaires apparaîtrons sous une forme ou une autre car ils répondent tout de même à des besoins (sans juger de leurs pratiques). Deux exemples tout bêtes parmi des dizaines :
Si ça devient sérieux et que tu laisses s'écouler quelques dizaines/centaines d'années il n'y a pas de raison objective que le résultat soit bien différent.
[^] # Re: Bitcoins!
Posté par dave . Évalué à -3.
Des assurances sur des bitcoins, je ne leur vois pas beaucoup d'avenir. Ou alors ce serait le marché type pour expert en sécurité avec ce genre de discours :
« Nous garantissons la sécurité de vos bitcoins. Nous les gravons sur des DVD en mode encrypté, les phrases de passe sont connues de nous seul et nous les cachons dans notre slip pour plus de sécurité. ».
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Bitcoins!
Posté par barmic . Évalué à 5.
Tu pense donc que bitcoin va rester un truc de geek qui fait de multiple backup placés à différents endroits géographiques. Nous sommes d'accord, mais ce ne seras donc pas utilisés par les entreprises.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bitcoins!
Posté par dave . Évalué à 1.
Je ne pense pas que le bitcoin crédit a de l'avenir. La masse monétaire totale tendant à diminuer, le crédit (c'est à dire louer des bitcoins avec un certain rendement en bitcoin) me paraît très difficile car la rente en dollar (et à BTC fixé) tendra à augmenter invariablement au cours du temps.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
# Les 12 travaux d'AstEBICS
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 9.
J'ai eu l'occasion de tester, et même d'essuyer quelques plâtres. Sur le principe et les implémentations, c'est de la technique, et çà roule à peu près. Seules les banques ont des modules "serveur" et les clients sont en mode "client", ils poussent des messages d'ordre de virement par exemple et demandent à recevoir des avis de virement par exemple.
Par contre, coté procédure chez nos amis les banquiers, c'est pas de la tarte. Mention spéciale au Crédit Agricole (Différents prestataires avec des procédures différentes pour chaque caisse - formulaires, signataires, moyens d'échanges des hashs de clé, etc.).
Je ne dirai pas quelle banque m'a demandé mes certificats (en plus des hash !) en clair dans un FAX (C'est génial).
J'ai beaucoup aimé aussi le "Ah non, on a pas de serveurs de tests, envoyez nous un virement de test en production".
Sinon concernant les formats XML/SEPA, on va bien rire, et il faudra faire un autre journal mais pour l'instant, beaucoup se contentent de migrer ETEBAC vers EBICS et c'était déjà un gros morceau.
On avait à disposition des messages EDIFACT qui marchaient très bien (au pire on pouvait les faire évoluer pour couvrir nos besoins) et qui étaient mondiaux, et les européens se sont mis à plusieurs (mais pas tous) pour pondre des normes spécifiques à l'Europe, basé sur du XML.
Good job,
Enzo Bricolo
[^] # Re: Les 12 travaux d'AstEBICS
Posté par epot (site web personnel) . Évalué à 5.
En Belgique, on n'a pas de gouvernement ;-) mais SEPA est une réalité depuis au moins 2 ans. Lorsque je travaillais dans une boite faisant du logiciel bancaire, c'était le sujet chaud du moment. Maintenant, SEPA et les virements/domiciliations/etc. bancaires sont bien implémentés/implantés dans les différentes banques (les anciennes méthodes de virements et domiciliations existent toujours pour les particuliers). En Belgique, c'est Febelfin qui a chapeauté le processus de transition et je dois dire que c'était assez transparent (i.e. les specs sont gratuitement disponibles sur leur site web). Voir les normes sur SEPA Belgium et les standards sur Febelfin.
[^] # Re: Les 12 travaux d'AstEBICS
Posté par Zenitram (site web personnel) . Évalué à 4.
Question con : si c'est européen, pourquoi il y a des normes sur des sites nationaux?
[^] # Re: Les 12 travaux d'AstEBICS
Posté par Frédéric Heulin . Évalué à 9.
Pour créer des frontières là où il n'y en a pas ...
En EBICS, par exemple il y a des différences subtiles dans l'utilisation des messages (FDL pour la récupération des informations) qui différent de manière technique mais pas de manière fonctionnelle entre la France ... et l'Allemagne !
Autant pour des normes qui sont unifiées avec l'âge je peux comprendre, mais là ...
Sinon EBICS T et TS, c'est vendu comme des protocoles successeurs respectivement d'ETEBAC3 et ETEBAC5 (version sécurisée) normes utilisées sur X25.
Les différences avec FTPS :
- FTPS est un protocole de transport uniquement
- EBICS est un protocole fonctionnel qui définit des messages d'échanges bancaires.
le protocole de transport est de l'HTTPS.
Pourquoi l'HTTPS plutôt que le FTPS ? :
- Il n'y a pas une grosse volumétrie.
- visiblement les gens préfèrent. Une norme comme l'AS2 (S/MIME sur HTTP/S) est largement déployé alors que l'AS1 (S/MIME sur "EMAIL") ou AS3 (S/MIME sur FTP/FTPS) le sont beaucoup moins.
De plus, certains voient un avantage à avoir un webservice car on peut faire une forme de séparation entre administration réseaux (l'IT qui gère le routeur/firewall pour l'HTTPS) et administration fonctionnelle (EBICS), une fois les routes établies.
[^] # Re: Les 12 travaux d'AstEBICS
Posté par cbo . Évalué à -3.
Kamoulox !
[^] # Re: Les 12 travaux d'AstEBICS
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
Faut juste faire gaffe à la salière
[^] # Re: Les 12 travaux d'AstEBICS
Posté par tagada . Évalué à 1.
C'est sûr que c'est bien implenté, avec tous les tests qu'ils ont fait, surtout celui-là : http://www.rtbf.be/info/societe/detail_la-poste-envoie-pres-de-50-000-paiements-par-erreur?id=5118653
# Ce service était jusqu'à présent gratuit
Posté par dinomasque . Évalué à 2.
Par curiosité, peux tu me citer au moins une banque française qui proposait gratuitement les virements de masse à sa clientèle entreprise ?
BeOS le faisait il y a 20 ans !
[^] # Re: Ce service était jusqu'à présent gratuit
Posté par dinomasque . Évalué à 2.
Ah et au fait, la plupart des banques proposent des outils de remises en masse par le web. Aucune entreprise n'est obligée d'utiliser Swift ou EBICS.
BeOS le faisait il y a 20 ans !
[^] # Re: Ce service était jusqu'à présent gratuit
Posté par tagada . Évalué à 1.
Malheureusement, ça va disparaître progressivement, EBICS va être imposé.
[^] # Re: Ce service était jusqu'à présent gratuit
Posté par dinomasque . Évalué à 2.
Imposé par quelle banque ?
Pour les petits remettants, la remise par site web reste pertinente.
BeOS le faisait il y a 20 ans !
# Hors de prix ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
c'est une blague ? ce n'est rien du tout pour une boite. Si elle utilise un tel système, c'est qu'elle a un volume d'argent à gérer suffisamment important pour rendre cette facture de 100 euros ridicule.
Si une boite est à 50-100 euros près par mois (surtout pour un truc qui lui permet de faire des économies de gestion manuelle), c'est qu'il y a un problème, et qu'elle est en train de couler.
Et transpac, c'était gratuit peut-être ?
[^] # Re: Hors de prix ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 0.
C'est 50-100 € par contrat (un contrat pour un compte en gros).
Ta boite a combien de compte en banque a ton avis ?
Enzo Bricolo
[^] # Re: Hors de prix ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Combien de comptes ont besoin d'avoir un truc automatisé?
[^] # Re: Hors de prix ?
Posté par Juke (site web personnel) . Évalué à 2.
Le jeudi 07 juillet 2011 à 23:27 +0200, Enzo Bricolo a écrit :
> Ta boite a combien de compte en banque a ton avis ?
pourquoi a t-elle besoin d'en avoir plusieurs ?
[^] # Re: Hors de prix ?
Posté par Kerro . Évalué à 2.
La plupart des banques sont tellement nulles que la majorité des entreprises qui font un CA correct ont plusieurs banques (et souvent plusieurs comptes par banque).
Ca permet d'avoir chez B une fonctionnalité que A ne propose pas, et réciproquement. Ca permet aussi de prendre un service spécifique dans une banque car il est moins cher, et un autre service dans une autre banque. Le tout revenant moins cher à cause des volumes.
Mais surtout ça permet de négocier. Tu veux me faire payer la carte bancaire ? Ah ? Bon ok, je ne la prends pas chez toi. Tu me fais payer les transactions de carte bancaire trop cher, je fais transiter par un autre compte. Le tout sans avoir à changer de banque à chaque fois. Ca se fait simplement en indiquant au comptable d'utiliser telle banque pour tel besoin.
C'est relativement efficace. Mais c'est le reflet de la médiocrité des banques.
[^] # Re: Hors de prix ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca ne dit toujours pas combien de ces comptes ont besoin d'un contrat pour les forts volumes.
[^] # Re: Hors de prix ?
Posté par Kerro . Évalué à 3.
Vu que ce n'était pas la question...
La seule entreprise à relativement fort volume que je connaisse bien (plusieurs millions d'euros d'achat/vente pas mois) n'a que 4 compte pour ces transactions.
Deux comptes dans une même banque française. Deux comptes dans une banque japonaise qui fait partie du même groupe.
Il y a également quelques comptes supplémentaires dans des banques diverses. A vue de nez une dizaine de comptes en tout. Pour une utilisation que j'ignore, mais je pense principalement pour isoler les transactions des regards internes. Par exemple les remontées d'argent vers la holding ne passent pas par un compte accessible à une autre personne que le pdg. Et à ces cons d'informaticiens, forcément, puisque la direction veut cacher le flux mais n'est pas fichue de rendre le flux invisible en demandant à la banque de faire le virement. A la place ils utilisent un logiciel installé sur un pc dédié pour faire une opération par mois. Question discrétion j'ai vu plus malin. Et bien sûr, les informaticiens du site vont dessus pour voir ce qu'il s'y passe car il y a des tensions depuis plusieurs mois.
[^] # Re: Hors de prix ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Désolé, c'était la question que je me posais devant les chiffres annoncés pour une "PME de 50 personnes".
Ca me parait déjà plus logiques comme chiffres, et c'est tout de suite moins "hors de prix", surtout que ça n'a absolument rien à voir avec le protocole utilisé (en FTPS avec ce qu'on veut au dessus, ça serait le même prix, ce n'est pas l'interface qui est facturée!), le prix peut très bien baisser tout en utilisant EBICS (pas de contraintes de son côté à lui...)
C'est tellement facile de trouver un bouc émissaire...
[^] # Re: Hors de prix ?
Posté par tagada . Évalué à 1.
Environ 50€/mois/canal EBICS + 25€/mois/accès portail web bancaire pour valider les virements + 100€/an/certificat = 1000€/an/compte environ.
4comptes donc 4000 €/an + 3000 € pour mettre à jour le logiciel de compta avec formation, soit 7000€ pour une PME de 50 personnes. C'est quand même un peu cher, non?
[^] # Re: Hors de prix ?
Posté par Zenitram (site web personnel) . Évalué à 3.
4 comptes avec EBICS nécessaires pour 50 personnes???
Certes, je ne connais pas trop le domaine, mais ça me parait quand même délirant. Que tu ais 4 comptes pour des raisons x ou y (compétition entre banques), OK. Que tu ais besoin de 4 comptes avec un énorme volume d'ordres à passer, comprend pas.
En plus, 7000/50 = 140 €/personne. Un peu comme le prix annuel d'une fiche de paye donc, pas la mort non plus. Sans compter que j'ai du mal à croire 4 comptes avec forts volumes de transactions nécessaires (allez, hop, un compte pour les forts volumes genre salaires mensuels, les autres en ponctuel par l'interface web) donc au final encore moins cher...
# XoT et fermeture transpac
Posté par Dabowl_75 . Évalué à 4.
La fermeture de Transpac et donc par conséquent celle de X25 n'est pas si dramatique.
Le protocole XOT (x25 over tcpip) est là pour faciliter les migrations.
Pour ma part, ayant travaillé dans le domaine monétique, cela fait déjà un moment que les infra sont prêtes pour faire du tout IP.
La fermeture de transpac, c'est la fin d'une grosse vache à lait pour FT et c'est aussi l'occasion d'envoyer à la retraite les rares irréductibles sachant encore administrer des commutateurs X25.
[^] # Re: XoT et fermeture transpac
Posté par phxonx . Évalué à -1.
Oui, enfin sauf que l'ordre d'arrivée des paquets n'est pas garantie, ni leur unicité. Et que du coup pour tout un tas de choses assez utile en x25 (Telle qu'une synchro base de temps, ce qui est légèrement utile en crypto, ou même simplement en téléphonie sécurisée) ca ne sert à rien.
Très honnêtement x25 et ATM devraient encore survivre un bon moment tant qu'on ne dispose pas de moyens de créer des circuits virtuels propres en IP.
[^] # Re: XoT et fermeture transpac
Posté par Dabowl_75 . Évalué à 2.
osef, on refile ce boulot ingras et coûteux à la couche supérieure et c'est marre
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . Évalué à 2.
???
C'est justement le boulot de TCP. Comprend pas.
[^] # Re: XoT et fermeture transpac
Posté par phxonx . Évalué à 0.
Non, TCP te garantie que les paquets seront remis dans l'ordre au final. Avec X25 le paquet ne peut pas sortir, c'est quasiment un pipe FIFO.
C'est très pratique quand tu as besoin de synchroniser des traitements - ce qui est assez fréquent en bancaire. Si tu glisse abilement un paquet "ping" dans un traitement par lot tu as une synchro assez balèze (Suffisament balaise pour permettre d'envoyer des Fax via SIP sans utiliser T.38 ou aucune autre base de temps.)
L'alternative pour synchroniser le tout c'est la base de temps. Mais là c'est lourd.
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . Évalué à 4.
Re-gni???
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Network_function
"Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the application program. Thus, TCP abstracts the application's communication from the underlying networking details."
Je ne comprend toujours pas : syncronizer, gérer les pertes de paquets, les doublons, c'est justement le boulot de TCP. Et vu les Terra-octets de connexions TCP qui se passent dans le monde en garantissant que ce sera dans l'ordre (comme par exemple LinuxFr en HTTP(S), imagine que ce soit dans le désordre...), je me permet de mettre en doute ton assertion. TCP c'est du FIFO, je demande une démo que ce n'est pas du FIFO (j'ouvre une connexion, j'envoie un octet A puis un octet B, je veux donc une démo que de l'autre côté il peut recevoir B avant A)
[^] # Re: XoT et fermeture transpac
Posté par windu.2b . Évalué à -1.
La réponse est ici
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . Évalué à 3.
Je dois être idiot, mais le lien que tu me files dit justement que ce sera dans l'ordre. Alors, certes, tu peux envoyer 2^32 paquets et la j'aurai un problème, mais ça se voit légèrement si 2^32 paquets sont perdus.
"Grâce aux numéros de séquence et d'acquittement, les systèmes terminaux peuvent remettre les données reçues dans l'ordre à l'application destinataire."
C'est ton lien. Dans l'ordre.
Oui, je suis idiot, mais j'ai besoin d'une meilleure argumentation, car les Terra-octets transmis par moi-même ont toujours été dans l'ordre en TCP.
[^] # Re: XoT et fermeture transpac
Posté par phxonx . Évalué à -1.
OK je te donne un exemple :
Si en tcp tu envoies sur un connexion
p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2
ils arriveront par exemple dans cette ordre là (les doublons ne sont pas une erreur)
p2 p3 p4 p4 p1 p5 p6 p7 pt1 pt1 p9 p11 p10 p12 pt2 p8
et ils seront remis dans le bon ordre par TCP
En x25 si tu envoie la même chose
p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2
ils arriveront
p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2
Pas possible que ca se passe autrement si la liaison n'est pas rompue.
Deux paquets sur la même liaison utiliseront de plus le même routage.
C'est très pratique pour faire de la synchronisation. Par exemple si en plus des infos qu'il transmet ton client envoie également à intervalle de temps fixe un paquet (ici pt1 et pt2) qui sert de base de temps.
Comme en x25 les paquets sont ordonnés pendant tout le transport, tout décalage entre deux ptx indique une augmentation de latence sur le circuit (ce qui lors de la transmission sécurisée d'un ordre boursier peut être un vrai problème).
TCP ne permet rien de semblable. Il faut donc faire la synchro des bases de temps à la mano, sur des routes qui peuvent varier d'un paquet à l'autre et c'est chiant. On passe littérament la moitié du temps en resync (et au passage on fout 20ou 30% de la bp à la poubelle).
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . Évalué à 6.
Je vois : en gros tu vires la couche TCP qui fait le boulot d'unicité et d'ordre d'arrivée, et après tu dis "l'ordre d'arrivée des paquets n'est pas garantie, ni leur unicité." quand on parle de TCP/IP, euh... Désolé, mais non, c'est pas comme ça qu'on regarde un protocole et qu'on dit qu'il y a un ordre ou une unicité, on ne vire pas une couche comme on a envie, TCP fait partie de la règle du jeu, et
"p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2"
arrive bien comme ça :
"p1 p2 p3 p4 P5 p6 pt1 p7 p8 p9 p10 p11 p12 pt2"
de l'autre côté.
Qu'il y a un désordre au niveau IP, oui c'est connu (mais on s'en fou, on a TCP, c'est son objet même)
qu'il y ai une latence, oui, c'est connu.
Mais dans le cas d'une transmission SEPA, on s'en fout de la latence non? Alors certes X25 mais surtout ATM (grace aux contrats) vont encore exister pour des cas hyper mega spécifiques, mais le fait que TCP/IP ne t'offre pas une garantie de latence ne te permet pas d'affirmer que l'ordre et l'unicité ne sont pas gérés par TCP/IP : ils le sont.
Tout ce que ça te permet de dire est qu'il y a des problèmes de latence avec TCP/IP, du fait de la couche qui va bien pour réordonner le bazar en dessous (bazar qui n'existe pas avec X25 donc plus de latence introduite par TCP/IP, on est d'accord sur ce point je pense)
[^] # Re: XoT et fermeture transpac
Posté par phxonx . Évalué à -4.
Une dernière fois pour la route.
Au niveau TCP (IP ou autre chose) la couche de transport ne garantie pas l'ordre ni la non duplication des paquets.
En d'autres termes ce qui est émis par le routeur A en début de chaine n'est pas forcément identique à ce qui est reçu par le routeur B en find e chaine.
Même si TCP garanti que le routeur B sera capable de recomposer correctement ce qui a été émis par le routeur A.
En x25, au niveau transport même on a une garantie de cohérence du flux (le paquet N arrivera forcément après le paquent N-1 si il arrive). Et si cette cohérence n'est pas respectée, on reprend tout depuis l'erreur. (ie si le paquet 5 arrive avant le paquet 4 il faut réemettre les paquets 4, 5, 6 etc. )
Donc si on a besoin d'une synchro x25 fait 95% du boulot, TCP 0%.
Et faire de la synchro base de temps sur TCP c'est juste l'horreur.
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . Évalué à 3.
Je te cites : "et ils seront remis dans le bon ordre par TCP"
Faudrait savoir.
Et? Ce qui compte c'est qu'à la fin j'ai mes données dans l'ordre sans duplication. Et je l'ai tant que tu me démontres pas le contraire (ce qui va être dur car j'ai déjà dit que je transmet des paquets par milliards dans l'ordre et non dupliqué).
Je veux bien te croire. Mais ça n'a pas grand chose à voir avec l'ordre ni la non duplication. Tu ne m'as toujours pas démontré pour l'ordre et la non duplication, c'est ça dont on parle! La synchro n'est pas dans la demande de démonstration, je te demande de me démontrer comment on fait pour avoir des données dans le désordre avec TCP, ce que tu n'as toujours pas démontré (ou alors oui, je suis bête au point de ne pas comprendre... Mais continuerai à vivre avec mes données dans l'ordre et non dupliquées en TCP)
[^] # Re: XoT et fermeture transpac
Posté par phxonx . Évalué à -2.
Ordre d'arrivée des paquets
pipe Fifo
pas de garantie au niveau du transport
Je ne sais plus comment le dire. Pour la synchronisation on se fout totalement du fait que les paquets seront uniques et ordonnées au final. On les veut dans le bon ordre tout le temps. Ce que TCP, qui est asynchrone ne garantit pas.
x25 garantit un fil virtuel sur lequel tes paquets seront dans l'ordre, à la queleuleu et uniques. TCP non.
Après bien sur que TCP permet d'envoyer des données dans un ordre précis et de les récupérer à l'identique dans le même ordre. Mais je n'ai JAMAIS dit le contraire. Relis mes posts, j'ai dit que X25 et ATM avaient encore de beaux jours devant eux pour les opérations synchrones.
Et c'est tout ce dont j'ai parlé... Le reste ca vient de toi.
[^] # Re: XoT et fermeture transpac
Posté par shbrol . Évalué à 2.
Je crois que c'est une question de point de vue, toi phxonx tu est au niveau paquet, et Zenitram est au niveau données émises et recues par les clients.
Si j'ai bien compris le propos, Alice envoie deux données D1 et D2, en les plaçant respectivement dans des paquets P1 et P2. Comme le réseau fait ce qu'il peut, a l'arrivée on reçoit dans l'ordre P2 puis P1, mais comme la vie est bien faite, c'est P1 qui sera traité avant P2 et donc Bob a bien les données dans l'ordre D1 puis D2.
Alice, Bob et Zenitram sont contents, parce que les données reçues sont identiques a celles qui ont été envoyées, mais phxonx n'est pas satisfait parce que c'est l'ordre des paquets qui l'interesse.
[^] # Re: XoT et fermeture transpac
Posté par Zenitram (site web personnel) . Évalué à 4.
Mmm... Je dirai surtout que la notion de paquet n'est pas la même : je pense TCP (si j'envoie un paquet TCP D1 puis D2, je les recevrai dans l'ordre, donc avec XOT qui est au dessus de TCP ce sera dans l'ordre), et lui pense IP (oui, c'est dans le désordre, mais on ne parle pas de IP, on parle de TCP).
Rappel : je réagissais sur "Le protocole XOT (x25 over tcpip) est là pour faciliter les migrations." puis "Oui, enfin sauf que l'ordre d'arrivée des paquets n'est pas garantie, ni leur unicité.". Si les XOT se base sur TCP, ben il ne m'a toujours pas expliqué comment ça pouvait être dans le désordre, il se borne à parler d'IP (et comme XOT est indiqué comme au dessus de TCP, je m'en fou d'IP, c'est le problème de TCP).
Donc ma question est toujours : comment XOT peut être dans le désordre si ça se base sur TCP? Bizarrement, la réponse est pas sur ça, mais sur IP la couche dont on se fout complet pour l'ordre et l'unicité. J'attend toujours une réponse compréhensible.
[^] # Re: XoT et fermeture transpac
Posté par phxonx . Évalué à 0.
TCP est asynchrone depuis des années. On peut envoyer les paquets dans le désordre et ils seront acquittés dans le désordre.(acquittement sélectif)
Les options de Fast retransmit et de Fast recovery peuvent mener à la duplication de paquets.
Même la gestion de congestion peut mettre la grouille avec certains algo.
La seule fois ou j'ai parlé d'IP c'est pour dire TCP (IP ou autre chose). De façon à bien signaler que je ne parlais pas IP.
[^] # Re: XoT et fermeture transpac
Posté par ckyl . Évalué à 3.
Non c'est complétement faux.
- Si tu te places d'un point de vue utilisateur de la pile TCP/IP tout ce que tu peux dire c'est "transmet moi ce buffer" et "donne moi un buffer si il y a des données dispo". TCP/IP t'assures que ton stream sera identique en émission et en réception point final. Il n'y a aucune notion de paquet ou autre.
- Si tu te places du point de vue de la couche TCP alors c'est complétement faux. Le paquet arrivent dans un ordre indéterminé et sont réordonnés par le destinataire.
Jamais bossé avec X25, mais un protocole basé sur des virtual circuit ou du circuit switching par définition assure, entre autre, que les paquets ne peuvent pas arriver dans le désordre. Il n'y a donc pas de travail de re-ordonnancement à faire côté destinataire.
Si un point commun entre les deux est que le stream de l’émetteur et du récepteur sont identiques. Leur différence de fonctionnement change pas mal de choses sur les autres propriétés. Ça n'a pas d'importance si tout ce qui t'intéresse c'est que les bits émis et reçus soit identiques. Mais si tu désires d'autres propriété, notamment du point de vue latence et synchro, ca peut tout changé et demander beaucoup plus de travail au niveau de la couche applicative.
[^] # Re: XoT et fermeture transpac
Posté par pasScott pasForstall . Évalué à -2.
Non, les paquets ne seront pas recu dans l'ordre. Enfin, peut etre, peut etre pas.
Et tu peux dire ce que tu veux, c'est comme ca.
Par conte, ils seront reordonnes par ta pile tcp a la reception pour reconstruire un buffer qui, lui, sera ordonne comme il le faut. Mais on est plus dans la couche tcp la, mais au dessus.
Monsieur est interesse par l'ordonnancement au niveau transport, t'as beau lui dire que sisisi, une fois sorti de tcp, ca marche, il te dit que ca marche pas parce qu'il le veut au niveau transport. Ce a quoi tu lui reponds que bien sur que si, au niveau au dessus, c'est ordonne, et que donc ca marche.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# Station de test Ebics
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
Station de test ebics
Chez Webank, vous pouvez vous créer un compte de test en 3 minutes
https://qualif-ebics.webank.fr/qualif-ebics/private/subscrib.do?parameter=prepare
Tester ce soir, ça répond !
Bien joué,
Enzo Bricolo
[^] # Re: Station de test Ebics
Posté par tagada . Évalué à 1.
Pour valider les ordres de virement, on a le choix :
- de la signature envoyée par fax (marche à tous les coups mais pas pratique)
- de payer un abonnement supplémentaire à chaque portail de chaque banque, en plus de l'abonnement au canal EBICS.
- d'utiliser la clé 3sKey de SWIFT qui ne marche pas avec Firefox : voir réponse ci-dessous.
Objet SC - 3SKey support question
De 3skey.Support Add contact
Cc Support Add contact
Date Aujourd'hui 17:18
Hello,
There are currently no plans to support Ubuntu or any other Linux distribution. Future Firefox support is being discussed but we have no deadline yet.
Note that TSE and Citrix are not officially supported even in a windows server environment. As of now only Windows XP SP3, Windows Vista SP1 and Win7 are supported.
Don’t hesitate to contact the 3skey support on +33 1 57 32 35 36 if you have other questions, please mention case reference SC 41682017.
Kind regards,
[^] # Re: Station de test Ebics
Posté par ArnaudB . Évalué à 1.
bonjour,
Pour info, la compatibilité citrix et TSE est désormais validée:
http://www.swift.com/3skey/fr/help/compatibility.html
Firefox viendra prochainement.
[^] # Re: Station de test Ebics
Posté par tagada . Évalué à 2.
Finalement, la 3SKEY de SWIFT ça ne va pas. Certaines banques la refusent pour valider les ordres de virement multi-bancaires. Chacun veut proposer sa solution qui ne sera pas acceptée par les autres, c'est le cirque comme d'habitude.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.