Discussion :

[gazelle39]

Bonjour,

je vais bientôt finir mon stage de fin d'étude (Master), développeur en JAVA JEE prestataire dans une grande entreprise d'assurance.

aujourd'hui l'entreprise cliente ma proposé de poursuivre ma mission chez eux (toujours prestataire) mais je vais pas faire que du développement Java JEE, c'est plutôt de déterminer pourquoi un tel traitement (Batch Spring) est planté et faire les corrections nécessaire.

là je suis un peu perdu et je ne sais pas quoi répondre, car mon stage est très bien passé et l'entreprise veux me garder parce que ils ont apprécies mes qualités techniques et relationnels et veulent que je remplace un membre de l'équipe qui est difficile.

ma question c'est, vu que et je vais m'éloigner du dev que je voudrais le faire, mais je ne sais pas car pendant un entretien une RH m'a convaincu que on ne fais pas Bac+5 pour devenir un développeur seulement, et je serai prestataire ça me fais peur à un certain moment ma mission fini (je vais faire mon mieux pour que le client final me garde -> je rêve un peu) et je trouve que mes compétence en dev en chuter.

voilà je suis un peu perdu et j'ai besoin de vos conseilles
Merci par avance

[gangsoleil]

Bonjour,

il y a plusieurs choses dans ton message.

Quel est ton contrat actuel avec ton employeur ? Stage, CDD, CDI, autre ?

Le client veut te garder en prestation, c'est plutot positif. Maintenant, il t'explique aussi que c'est pour une tâche particulière, il faudrait donc que tu arrives à voir combien de temps ils pensent te garder -- 1 mois, 1 an, autre -- et s'ils ont déjà prévu des choses derrière.

Une fois que tu auras ces informations, tu pourras voir avec la SSII pour négocier un contrat de travail (si tu es en stage actuellement).

[gazelle39]

1- un stage de fin d'étude
2- le poste que je vais occuper pour une mission longue (voir très longue) car c'est obligatoire dans l'équipe qu'il y a quelqu'un qui fait ce travail.

pour la suite, peut être qu'il me prennent pour une mission de quelques années pour mieux me connaitre avant qu'ils me gardent définitivement chez eux , à condition que je travaille sérieusement comme pendant le stage (pour cette raison veulent me garder)

[gangsoleil]

le poste que je vais occuper pour une mission longue (voir très longue) car c'est obligatoire dans l'équipe qu'il y a quelqu'un qui fait ce travail.

J'avoue que je ne comprends pas bien : tu parles d'une fonctionalité à corriger car elle plante, ce qui peut certes être long, mais bon, de là à envisager que ça prenne plusieurs mois, j'ai du mal.


J'ai oublié un point :

on ne fais pas Bac+5 pour devenir un développeur seulement

Comme beaucoup de gens, il ne sait pas ce qu'est un développeur. Oui, il n'est pas (forcément) utile de faire des études longues pour faire du développement de base, c'est à dire si un groupe de personnes s'occupe de faire des spécifications détaillées, et que le développeur est limité à pisser du code (presque) sans réfléchir.
Mais être développeur, c'est aussi avoir un (technico-)commercial qui vient te voir pour te dire "Un client me demande combien ça coûterait de faire ça, je pense que c'est X, qu'en penses-tu, on peut voir ensemble", puis ensuite prendre en charge tout le développement, depuis la conception jusqu'à la livraison. Alors bien sûr, si c'est un projet à 2000 jours, tu ne ponds pas les specs comme ça, mais ne croit pas que les specs de ces projets seront forcément détaillées, et souvent, c'est au développeur de le faire.

[gazelle39]

J'avoue que je ne comprends pas bien : tu parles d'une fonctionalité à corriger car elle plante, ce qui peut certes être long, mais bon, de là à envisager que ça prenne plusieurs mois, j'ai du mal.

je te donne un peu de détails sur l'environnement du travail, je travail dans une grande entreprise d'assurance, dans une équipe qui gère le calcul de paie (juste une partie)des salariés. le système informatique est distribué entre plusieurs application (interne/externe de notre équipe) et l'échange des données se fait via des fichiers qui seront traiter avec des batchs. le problème avec ces traitements quand ils plantent (ce qui arrive souvent, si par exemple un fichier ne respecte pas un certain format.. ou pour des raisons de sécurités), on doit intervenir immédiatement, sinon, il y aura des retards dans la paie des salariés ce qui est interdit !!!

à part ça, il y a aussi des fonctionnalités à développer ou à améliorer (en Java / Java JEE)

J'ai oublié un point :
Comme beaucoup de gens, il ne sait pas ce qu'est un développeur. Oui, il n'est pas (forcément) utile de faire des études longues pour faire du développement de base, c'est à dire si un groupe de personnes s'occupe de faire des spécifications détaillées, et que le développeur est limité à pisser du code (presque) sans réfléchir.

j'avoue que j'ai fais des études (à l'étranger et en France) dur et de qualités dans une université bien classé et mes rêves sont au dessus de mes capacités. j'étais pas conscient du "on fait pas Bac+5 juste pour être un développeur" que après 3 mois de mon stage quand j'ai demandé à mon tuteur de me donner des choses à développer avec plus de challenge, car j'ai bien maîtrisé l'environnement du travail et en moins d'une semaine je fini le développement d'une nouvelle fonctionnalité (+2 semaines pour que le tuteur valide le travail s'il a le temps et faire les différents tests avec les spécifications (techniques et fonctionnelles) détaillés

Mais être développeur, c'est aussi avoir un (technico-)commercial qui vient te voir pour te dire "Un client me demande combien ça coûterait de faire ça, je pense que c'est X, qu'en penses-tu, on peut voir ensemble", puis ensuite prendre en charge tout le développement, depuis la conception jusqu'à la livraison. Alors bien sûr, si c'est un projet à 2000 jours, tu ne ponds pas les specs comme ça, mais ne croit pas que les specs de ces projets seront forcément détaillées, et souvent, c'est au développeur de le faire.

j'ai pas d’expérience en terme d’estimation des coûts, mais pour les specs, je l'ai déjà fais pendant mon stage et à part les fautes d'orthographe (je viens de l'étranger) y a rien à signalé et mon tuteur et un chef de projet MOA trouvent que les specs sont clairs et bien fait.

pour finir, j'ai répondu au client que je vais continuer ma mission avec eux.
Merci pour vos réponse

[Carhiboux]

Salut,

tu vas faire de la TMA quoi. Et il leur manque un mec qui comprenne de quoi il retourne. La TMA, si c'est bien de ça qu'il s'agit, c'est très particulier comme activité. Il faut aimer passer du coq à l'âne, et être très curieux, parce qu'en général, il y a des grands périmètres et il est difficile de se contenter d'avoir un vernis sur chaque sujet.

Après, si le poste te plait, que le client te plait, c'est toi qui sait.

Mais clairement, si tu veux faire du pur dev, c'est peut être pas le meilleur job. Par contre, si tu veux en savoir le maximum sur le SI de ton client... là pour le coup, c'est jackpot. Le tout est alors de ne pas trop te rendre indispensable, sinon tu leur sera tellement précieux en tant que presta que tu ne passera jamais interne.

Juste, ce qui me semble bizzare, c'est que si le fichier plante, c'est l'application émettrice qui devrait être corrigée... sinon à la prochaine émission c'est rebelote...

Bon courage.

[el_slapper]

(.../...)Juste, ce qui me semble bizzare, c'est que si le fichier plante, c'est l'application émettrice qui devrait être corrigée... sinon à la prochaine émission c'est rebelote...(.../...)

Toi, tu n'as jamais fait de maintenance dans un grand compte. Ou les lourdeurs administratives et la peur du changement font préférer une correction de données de 2 jours tous les mois à une correction définitive et unique de 5 jours. J'ai eu une application émettrice qui envoyait parfois un code agence à la place du code banque, parce-que sa base était corrompue, et on a fini par mettre une rustine qui recalculait le code banque si on ne savait pas l'identifier(ça marchait à tous les coups, parce-qu'il n'y avait pas de code banque qui soit aussi code agence).

Dans un monde idéal, tu as 100% raison, mais les grands comptes sont loin d'être un monde idéal.

[gazelle39]

le client m'a parlé de ce que je vais faire, c'est du dev (beaucoup en plus ) mais il y a un œil sur la maintenance.
la mission très intéressante et je ne pense pas que je vais trouver mieux ailleurs

[Carhiboux]

Toi, tu n'as jamais fait de maintenance dans un grand compte. Ou les lourdeurs administratives et la peur du changement font préférer une correction de données de 2 jours tous les mois à une correction définitive et unique de 5 jours. J'ai eu une application émettrice qui envoyait parfois un code agence à la place du code banque, parce-que sa base était corrompue, et on a fini par mettre une rustine qui recalculait le code banque si on ne savait pas l'identifier(ça marchait à tous les coups, parce-qu'il n'y avait pas de code banque qui soit aussi code agence).

Dans un monde idéal, tu as 100% raison, mais les grands comptes sont loin d'être un monde idéal.

Je sais bien, mais j'ai toujours gueulé suffisamment fort et suffisamment longtemps pour que les choses bougent à un moment ou un autre.

Puis je suis dans une boite ou plus que la lourdeur administrative, c'est les oursins dans les poches qui dominent! Donc si je leur démontre par A + B que le ROI est réel en deux ou trois mois, c'est vite fait!

[Glutinus]

Toi, tu n'as jamais fait de maintenance dans un grand compte. Ou les lourdeurs administratives et la peur du changement font préférer une correction de données de 2 jours tous les mois à une correction définitive et unique de 5 jours. J'ai eu une application émettrice qui envoyait parfois un code agence à la place du code banque, parce-que sa base était corrompue, et on a fini par mettre une rustine qui recalculait le code banque si on ne savait pas l'identifier(ça marchait à tous les coups, parce-qu'il n'y avait pas de code banque qui soit aussi code agence).

Dans un monde idéal, tu as 100% raison, mais les grands comptes sont loin d'être un monde idéal.

Je sais bien, mais j'ai toujours gueulé suffisamment fort et suffisamment longtemps pour que les choses bougent à un moment ou un autre.

Puis je suis dans une boite ou plus que la lourdeur administrative, c'est les oursins dans les poches qui dominent! Donc si je leur démontre par A + B que le ROI est réel en deux ou trois mois, c'est vite fait!

J'avais une application où un utilisateur m'envoyait tous les mois un fichier pour restructurer les produits (produits AAA est en fait BBB... ça permettait de faire des reportings plus propres et donner les chiffres qu'ils voulaient), ils avaient fait un traitement spécifique alors qu'il y avait une IHM faite exprès pour son équipe !

Mais bon, t'avais beau expliquer le ROI, le client grand compte avait la parade : le bureau d'à côté fait une refonte du produit, de toute façon, mise en prod dans quelques semaines (apparemment ça faisait 5 ans la refonte, et ils y foutaient des sous... et à l'inverse l'appli en run était un véritable Jenga).

@Gazelle39 : d'un côté, faut pas s'inquiéter. Un développeur ne fait pas que coder from scratch ; il fait aussi du suivi de production et de la maintenance. Le tout est de savoir auprès de ton employeur combien de production est dédiée à ta tâche. Mais si tu penses qu'il y a anguille sous roche, mieux vaut ne pas mettre le petit doigt dans l'engrenage, au risque de te faire aspirer jusqu'au coude.