Discussion :

[Syarko]

Bonjour,



Je me permet de vous contacter pour un ami qui travaille dans une grande banque et qui prépare un exposé au sujet des informaticiens dans le milieu bancaire. Il faut savoir que de moins en moins d'informaticiens sont intéressés de travailler dans les banques "classiques", et se tournent plutôt vers les FinTech (généralement des start-up évoluant dans le domaine des services financier et bancaire avec des technologies innovantes, comme par exemple KickStarter pour le financement participatif, BankIn,...). Du coup cette personne souhaiterait savoir, à salaire égal, que choisirez-vous entre un poste dans une banque et un poste dans une FinTech et pourquoi ? Juste quelques points suffisent. Et si, comme dans mon cas, le milieu bancaire vous attire pas de manière général, vous pouvez aussi dire pourquoi.
Je sais pas si je suis dans le bon onglet pour poster ce genre de questions par contre :/.
Merci à ceux qui prennent le temps de répondre

[olivier50]

Bonjour, il faut prendre garde à l'intoxication et aux mots. Participatif, intelligence artificielle sont en très en vogue. Il y a des lobbys, des gens qui veulent vendre leur sauce.

Deux exemples:
-Le financement participatif: Unilend a fermé ses portes cette année: tapez le mot clé Unilend et lisez la presse.
-L'intelligence artificielle: un titre choc dans la presse "un meurtre élucidé grâce à une box intelligente": la police a écouté les enregistrements audio mais on parle de box intelligente: dans le temps on appelait ça un magnétophone. Et je ne parle pas de celui qui prétendait résoudre les problèmes d'emploi avec cette fameuse intelligence artificielle.

Bon dimanche.

[gangsoleil]

C'est quoi informaticien en milieu bancaire ? Front en js, back en cobol, middleware, ... ?

Pour ce qui est du positionnement des fintech, c'est souvent beaucoup de bruit pour rien...

Après, une partie des dev aiment bien le côté startups, d'autres privilégient les grands groupes, et il est tout de même rare d'aimer les 2. Donc pour moi, ces deux types de poste ne s'adressent pas aux mêmes personnes.

[pmithrandir]

Je pense que la banque est un des milieux les plus compliqué pourles informaticiens :
- une partie des postes implique la mise en place d'outils auxquels ont peu ne pas souscrire ethiquement parlant.(vous pouvez me proposer 3 fois mon salaire actuel pour faire des algo d'automatisation de la bourse...pas sur que je sois partant.
- des technos parfois très datées(cool est un exemple récurrent).
- Des structures lourdes et peu habituées a l'évolution.(a l'opposé de notre métier).

A coté de ca, elles offrent une grande stabilité, une progression de carrière en interne, des conditions favorable pour des emprunts / découvert, etc... qui peuvent constituer des avantagess non négligeable dans la vie.

Les startuop sont des startup avec leur lot de bon et mauvais coté.
J'aime beaucoup, mais ca demande d'être très ouvert d'esprit.

[yento]

FinTech = Finance + Technologie.

Travailler dans une banque, c'est travailler en FinTech. L'evolution habituelle c'est startup/autre => Banque d'investissement => Hedge Fund.

Les salaires ne sont pas egaux. Il n'y a aucune petite entreprise qui paye €100k, £200k ou $500k par an. Si les salaires etaient egaux, on ne se retrouverait pas tous en finance


"vous pouvez me proposer 3 fois mon salaire actuel pour faire des algo d'automatisation de la bourse...pas sur que je sois partant." => J’espère que tu considérerais quand même la proposition si elle se présente.
"Des structures lourdes et peu habituées a l'évolution.(a l'opposé de notre métier)." => Je sais pas ou t'es mais on ship toutes les quelques secondes en moyenne.

[Carhiboux]

Travailler dans une banque, c'est travailler en FinTech.

Non, les grosses banques ont aussi leurs services IT.

- une partie des postes implique la mise en place d'outils auxquels ont peu ne pas souscrire ethiquement parlant.(vous pouvez me proposer 3 fois mon salaire actuel pour faire des algo d'automatisation de la bourse...pas sur que je sois partant.

Tous les postes ne sont pas liés à la bourse. Et tous les postes liés à la bourse ne sont pas liés à des micro-transactions.

Dans les grandes banques, tu as des services dédiés aux crédits. Après, on peut penser ce qu'on veut des taux et des marges, n’empêche que si Monsieur ToutLeMonde devait attendre d'avoir mis de côté ses 300k pour s'acheter un 20m² à Paris, pas sur qu'il en serait capable puisque dans le même temps il devrait continuer à payer un loyer. Avec un crédit, ce qu'il ne paye pas en loyer passe en mensualité de remboursement, et au bout de 20 ans il est proprio.

Tu as des services dédiés à l'épargne bancaire, etc... etc... et plein d'autres services qui ne sont pas visible de l'extérieur (les référentiels, les risques, etc...)

[el_slapper]

Pour compléter la réponse de Carhiboux

- une partie des postes implique la mise en place d'outils auxquels ont peu ne pas souscrire ethiquement parlant.(vous pouvez me proposer 3 fois mon salaire actuel pour faire des algo d'automatisation de la bourse...pas sur que je sois partant.

ouais, enfin, j'ai fait une dizaine de missions en bancaire, pour à peu près autant d'années, j'ai eu exactement un seul doute éthique sur ce que j'avais à faire, et le service juridique à tranché(3 mois de boulot à la poubelle, mais ça, ça arrive partout). Même pas quand j'ai bossé sur les titres - mon rôle consistait à répercuter les impacts bancaires des ordres de bourse(en gros, alimenter la compta, en beaucoup plus compliqué).

- des technos parfois très datées(cool est un exemple récurrent).

Je suppose que tu veux dire COBOL. Effectivement, c'est daté. En même temps, pour qui n'a pas fait d'école d'info, ça ou autre chose, on ne voit pas la différence.

- Des structures lourdes et peu habituées a l'évolution.(a l'opposé de notre métier).

je vais mettre un bémol à ce que dit Yento, mais quand même. le COBOL, on le livrait en prod en quelques minutes(le temps que ça compile, c'était 2-3 commandes ISPF maxi, et pas des compliquées). Après, les gens du JAVA avaient d'autres contraintes. Genre, "pour livrer, il faut faire un dossier complet à la cellule d'intégration, qui crééra le build dans une semaine - et ça, c'est juste pour livrer dans le premier environnement de test". Je ne sais pas ce que fabriquaient les gens de la cellule d'intégration, mais ils n'avaient pas l'air de se tourner les pouces. Ca ne donnait pas envie de partir sur JAVA. Quand les gens du métier me demandaient une modif simple, des fois, c'était dans la poche en 10 minutes ni vu ni connu. Après, plus compliqué(de 1 heure à 120 jours), il fallait un budget. En JAVA, ce n'était pas possible.

Dit encore autrement, la lourdeur, elle n'est pas partout, et dépend fortement de choix individuels qui ont été faits à une époque passée, et qui se répandent partout. La méthode de build choisie chez ce client pour le JAVA était d'une complexité infâme. Celle choisie pour COBOL était d'une efficacité redoutable(ENDEVOR, c'est de la balle).

Après, il y a aussi la lourdeur des process. Et là, on est dans du built-in. Un banquier créatif est un mauvais banquier(pensez à Kerviel). Un informaticien non créatif est un mauvais informaticien. ca demande un certain sens de la godille pour faire ce qu'on a à faire, parfois. J'ai trouvé ça rigolo, mais c'était fatiguant, parfois, l'impression d'être un agent secret - au service de la puissance espionnée. C'est rigolo de voir leur tête quand ils se rendent compte que si le projet a réussi, c'est parce qu'on a pas respecté les règles. Rigolo et dangereux - j'aime l'odeur de poudre. De bons souvenirs. Ce n'est pas pour tout le monde, de toute évidence.

[Marco46]

je vais mettre un bémol à ce que dit Yento, mais quand même. le COBOL, on le livrait en prod en quelques minutes(le temps que ça compile, c'était 2-3 commandes ISPF maxi, et pas des compliquées). Après, les gens du JAVA avaient d'autres contraintes. Genre, "pour livrer, il faut faire un dossier complet à la cellule d'intégration, qui crééra le build dans une semaine - et ça, c'est juste pour livrer dans le premier environnement de test". Je ne sais pas ce que fabriquaient les gens de la cellule d'intégration, mais ils n'avaient pas l'air de se tourner les pouces. Ca ne donnait pas envie de partir sur JAVA. Quand les gens du métier me demandaient une modif simple, des fois, c'était dans la poche en 10 minutes ni vu ni connu. Après, plus compliqué(de 1 heure à 120 jours), il fallait un budget. En JAVA, ce n'était pas possible.

Toi tu parles du delivery lead time, lui il te parle de la deploy frequency.

Le delivery lead time c'est la durée entre un commit et un déploiement réussi en production. Et je parle bien de la production, pas d'un environnement de test.

La deploy frequency c'est ... la fréquence des déploiements en production.

Il te dit donc qu'ils ont un déploiement en prod chaque n secondes. C'est à dire un niveau d'excellence des pratiques DevOps correspondant à celui des GAFA.

Évidemment comme il travaille manifestement dans la City qui est à des années lumières de la France d'un point de vue technique c'est pas super étonnant. De ce que j'en sais en France on est plutôt sur des métriques de l'ordre de plusieurs semaines à plusieurs mois, les raisons sont multiples, lourdeurs administratives, incurie technique et fonctionnelle du fait du recours massif aux SS2I avec le turnover qui va de pair, résistance au changement, incompétence managériale, etc... Bref la France quoi

[pmithrandir]

"vous pouvez me proposer 3 fois mon salaire actuel pour faire des algo d'automatisation de la bourse...pas sur que je sois partant." => J’espère que tu considérerais quand même la proposition si elle se présente.

Autant que j'ai considéré la boite de jeusnde de hazard en ligne ou que je répondrai a un site porno.
Je lirai l'offre, et renverrai un email leur souhaitant bonne chance dans leur recrutement.

(et ca n'est pas valable pour tous les produits bancaires, juste sur la partie ordre de bourse ou finance pourrie).

"Des structures lourdes et peu habituées a l'évolution.(a l'opposé de notre métier)." => Je sais pas ou t'es mais on ship toutes les quelques secondes en moyenne.

Dans une banque classique française, je ne pense pas que ce rythme de deploiement soit généralisé. De mémoire, les structures bancaises étaient souvent très prudentes, et on peut le comprendre, pour limiter les impacts potentiels d'une faille systeme.

Mais les choses sont peut être mieux que les echos que j'en ai eu.

[Mathieu__]

D'un point de vue Business Intelligence je suis passé par Cofidis (Euro Information, Crédit Mutuel Ocean) : 2 mises en prod par an. (Il ne valait mieux pas les rater...)
Crédit Agricole : contexte BI/CRM, une fois par mois.

[el_slapper]

(.../...)Évidemment comme il travaille manifestement dans la City qui est à des années lumières de la France d'un point de vue technique c'est pas super étonnant. De ce que j'en sais en France on est plutôt sur des métriques de l'ordre de plusieurs semaines à plusieurs mois, les raisons sont multiples, lourdeurs administratives, incurie technique et fonctionnelle du fait du recours massif aux SS2I avec le turnover qui va de pair, résistance au changement, incompétence managériale, etc... Bref la France quoi

Ben non, je pouvais corriger en prod toutes les 5 minutes. Certes, pas toutes les 5 secondes, je suis battu. Mais oui, il est arrivé qu'il ne se passe pas plus de 5 minutes entre 2 mises en prod sur le même composant(avec un coupe de fil affolé entre les deux, et passage par tous les environnements intermédiaires). Et on était 140 cobolistes, chez ce client, et on pouvait livrer tous en même temps si on avait besoin. 300 secondes(5 minutes) divisé par 140, ça fait une livraison toutes les 2 secondes et demie, sans broncher - pour peu qu'il y en aie le besoin(rare, mais pas impossible).

Donc merci de garder ton ton agressif pour autre chose. Les livraisons toutes les semaines, c'était les gens du JAVA(je n'aurais pas aimé être à leur place). Et à d'autres endroits, c'était presque aussi performant. Le plus rigolo, c'est qu'il y avait un grand compte chez qui il y avait une procédure de "livraison à chaud".....mais au final, le temps de se souvenir comment ça marche et de trouver le grand chef qui va la valider, je faisais toujours une livraison standard. Le seul truc qui prenait du temps, c'était les compils. Chez eux, j'en avais pour 10 minutes à remonter test-intégration-recette-prod, sans compter le temps de test, évidemment. Quand je voulais du lundi au jeudi. Si à 16h15 on me demandait de monter en prod à 16h25, je pouvais.

(d'ailleurs, chez le premier client, quand on chiffrait, on était en concurrence avec les gens du JAVA, et on était 2 fois moins cher - et on dépassait moins, en moyenne, ça avait été mesuré. Je subodore que la facilité de livraison était pour beaucoup dans cet écart, je ne crois pas que les javaistes soient des gnous, en général).

Celà étant, oui, la France. mon chef, formé à Londres puis en Écosse, est catastrophé par les managers(et RH) français(au sens de la culture d'entreprise, pas au sens ethnique, hein) qu'on a ici en France. Entre le management par la panique, le management des projets mais surtout pas des gens, et le culte des horaires de fous, il y a en effet pas mal de mauvaises pratiques à extirper.

[Marco46]

Dans une banque classique française, je ne pense pas que ce rythme de deploiement soit généralisé. De mémoire, les structures bancaises étaient souvent très prudentes, et on peut le comprendre, pour limiter les impacts potentiels d'une faille systeme.

C'est pas de la prudence, c'est qu'on a 15 ans de retard sur les bonnes pratiques et un sous investissement chronique couplé à une stratégie RH mortifère pour l'IT. Je t'invite à lire Accelerate.

Livrer une tonne de modifs 2 fois par an c'est pas de la prudence, c'est de la stupidité. C'est bien plus dangereux pour le système que de livrer des micros trucs toutes les 10 minutes, bien plus facile à rollback.

C'est toute une mentalité qu'il faut changer.

[Marco46]

Donc merci de garder ton ton agressif pour autre chose.

Je vois pas bien en quoi j'ai été agressif envers toi, à moins que tu ne sois le CTO qui décide de la politique de gestion du SI tu n'es pas concerné par les critiques que je formule ...

[Marco46]

Ben non, je pouvais corriger en prod toutes les 5 minutes. Certes, pas toutes les 5 secondes, je suis battu.

Je me rends compte que tu n'as pas compris ce que je voulais dire.

Il ne parle pas du delivery lead time. Être capable pour un développeur de livrer toutes les 5 minutes ça veut dire que du commit en passant par le build et les environnements de tests au déploiement en prod ça ne prend pas plus de 5 minutes. C'est uuuuuuultra rapide comme métrique. Une heure c'est déjà très rapide.

La fréquence de déploiement c'est que le SI évolue toutes les n unité de temps peu importe le développeur qui effectue la modification. C'est une moyenne sur l'ensemble des développeurs et ça met en lumière l'agilité du SI. Tu peux avoir une deploy frequency de quelques secondes et un lead time de plusieurs heures. Et quand t'en es à ça tu t'appelles Amazon ou Google.

[gangsoleil]

Hello,

Évidemment comme il travaille manifestement dans la City qui est à des années lumières de la France d'un point de vue technique c'est pas super étonnant.

Juste pour remettre les pendules à l'heure : je connais certaines grosses banques du Royaume-Uni qui refusent les déploiements en prod plus d'une fois tous les X mois. Donc ne généralisons pas sur "la France met 2 release par an là où les anglais en mettent 2 par minutes", car ce n'est pas vrai.

[Mat.M]

Évidemment comme il travaille manifestement dans la City qui est à des années lumières de la France d'un point de vue technique

hé ho ! Nous on a la French Tech donc on ne fait pas de critiques

d'ailleurs si quelqu'un sait à quoi ça sert et me l'explique je lui en serais reconnaissant

[el_slapper]

Je me rends compte que tu n'as pas compris ce que je voulais dire.

Il ne parle pas du delivery lead time. Être capable pour un développeur de livrer toutes les 5 minutes ça veut dire que du commit en passant par le build et les environnements de tests au déploiement en prod ça ne prend pas plus de 5 minutes. C'est uuuuuuultra rapide comme métrique. Une heure c'est déjà très rapide.

La fréquence de déploiement c'est que le SI évolue toutes les n unité de temps peu importe le développeur qui effectue la modification. C'est une moyenne sur l'ensemble des développeurs et ça met en lumière l'agilité du SI. Tu peux avoir une deploy frequency de quelques secondes et un lead time de plusieurs heures. Et quand t'en es à ça tu t'appelles Amazon ou Google.

Ah, certes, mais là, ça dépend aussi de la taille du bouzin. Parcequ'une petite structure, désolé,elle ne livre pas en prod toutes les 10 secondes. Encore une fois, sur ce système COBOL, on était 140. Gros, mais pas énorme. ET toutes les modifications ne prennent pas 30 secondes(condition sine qua non pour que les 5 minutes, ça passe, hein, il y a des limites). Certaines peuvent prendre plusieurs jour(quand tu fait un truc nouveau de zéro, tu attends d'avoir un truc complet et cohérent avant de livrer, un demi composant jamais appellé en prod, ça pollue), et pendant ce temps là, tu ne livre pas. Quand tu as 3000 devs, je conçois que ça change en permanence. A 140, il y en a peut-être 30/40 qui vont livrer tel jour, de 1 à 20 fois, avec mettons une moyenne de 5 fois. ça fait 200 livraisons par jour. Ca n'est pas déconnant. Rapporté au nombre de programmeurs chez Google, tu verras que sur cettemétrique, ça n'est pas si mauvais. C'est une métrique de masse. Si je la pousse à l'extrême, mon père bosse seul. Il livre en prod quand le client le demande, souvent moins d'une fois par mois(même si ça peut être 10 fois dans la même journée, lors d'un démarrage). Fatalement, face à Google et ces dizaines de milliers de programmeurs, il lire moins souvent. Est-il moins agile pour autant? Non. Elle est pourrie, cette métrique, c'est bien plus une métrique de taille que d'agilité.

Après, si ton message, c'est "une version tous les six mois, c'est caca", tu prêches un convaincu. Je dis juste que les problèmes d'agilité soulevés ne sont pas présents partout dans le monde bancaire. Et que one peut être parfaitement agiles, pour peu que des gens de qualité aient mis en place le système. Et oui, on trouve des gens de qualité dans les grands groupes bancaires Français. Pas assez à mon gout(à cause d'une politique RH à chier, essentiellement, mais pas que), mais on en trouve, et certains ont mis en place dès les années 80 des systèmes très, très performants et agiles. Et que tous les connards qui ont essayé de les rigidifier s'y sont cassé les dents. Ce qui va à l'encontre du poncif "on ne peut pas bosser en bancaire, la moindre modif demande 6 mois de process". Ce poncif est faux, j'ai fait, sans même passer par les circuits urgents, des modifs express en pas plus de 10 minutes chrono, sur 3 sites différents. Jusqu'en prod. Sur des données comptables ou assimilées(données contrat assurance vie, données référentiel cartes bleues, données précomptables issues des mouvements de titres, etc.....)

Faut pas croire que les GAFA c'est des dieux et que le reste du monde c'est de la merde. D'accord, de la merde, il y en a beaucoup, mais quand on la nettoie, on peut trouver des diamants. Même en bancaire.

[el_slapper]

hé ho ! Nous on a la French Tech donc on ne fait pas de critiques

d'ailleurs si quelqu'un sait à quoi ça sert et me l'explique je lui en serais reconnaissant

La French Tech, en gros, c'est un incubateur à startup. Rien de transcendant, mais il y a aussi des gens sérieux. Ca aide à trouver des financements et ça centralise partiellement les compétences. Rien de transcendant, juste un petit plus. Qui peut être bien utile à certains, je le vois à Montpellier.

[Mat.M]

140 personnes sur un projet en COBOL ?
C'était à Bangalore ?

[yento]

lead time vs frequency

La difference valait le coup d'etre remarquee. Elle ne s'applique pas dans notre cas particulier parce que c'est quasiment le meme chiffre.
Par exemple, si une modification prend une minute et qu'il y a plusieurs milliers de développeurs travaillant en parallèle, ca fera une frequency et un lead time tous les deux autour d'une minute.

En etant realiste, n'importe quel changement prend un minimum d'une minute le temps de cliquer quelques boutons et de traverser le commit, lint, build, unit tests, packaging, release to 100 datacenters.
Ca peut facilement etre plus selon les etapes, surtout s'il y a des tests lourds, mais grosso merdo n'importe quel changement de code devrait etre realisable en 5 minutes (a condition de savoir quoi changer) et livré sur 1000 serveurs ou bureaux.

Il y a d'autres parties de la banque et d'autres requetes qui prennent plusieurs jours, voir une semaine entiere, mais pas un vulgaire changement de code.


Plus important que ca. Vous devriez faire la nuance entre bank et investment bank.
Les banques d'investissement, surtout les meilleures et du cote du front office, sont a la pointe de la technologie et des bonnes pratiques. C'est un centre de recherche pour générer du pognon.
Le reste, c'est la roulette russe. Cela dit, el slapper sur cobol et mainframe, ca touchait probablement des comptes clients et c'etait de bonnes conditions de travail.