Ingénieur d'etudes et développement - Ca consiste en quoi dans la réalité ?

[Titi41]

Bonjour,

C'est un libellé de poste qui revient assez souvent, mais qu'est-ce que ca veut dire finalement ?

Pour poser ma question d'une façon plus globale, est-ce qu'un débutant en SSII (ce que je vais bientôt être) ne fait que du développement ou travaille aussi sur des dossiers ou autres points moins techniques ?

[Glutinus]

Ingénieur d'études et développement, c'est le terme pour indiquer que l'on veut un développeur avec un bac+5. Comme son nom l'indique, tu fais en majeure partie du développement (de l'analyse, des tests...)

De manière générale, un débutant fait effectivement du développement, ne serait-ce que pour rentrer dans le monde de l'entreprise (s'il n'a pas fait d'alternance), apprendre des technos et voir les différentes couches du projet. Après, s'il s'est bien préparé, un débutant peut tenter de débuter dans l'AMOA ou en tant que chef de projet ; je dirai juste que c'est plus rare (on laisse rarement la gestion à quelqu'un qui n'a pas d'expérience dans ce domaine) et qu'il faut s'imposer de soi.

[Titi41]

Merci pour ta réponse. Mais est-ce que c'est vraiment du développement tout le temps ?
Quelqu'un arrive avec les spécifications, et on code ?

[Glutinus]

Alors là je dirais c'est extrêmement variable...

Ca peut être de la maintenance, dans laquelle tu reçois une fiche anomalie. Il faut alors récupérer le(s) bon(s) fichier(s) de code et les corriger, ou démontrer que ce n'est pas vraiment une anomalie. Et éventuellement chercher dans une spec technique... lorsqu'elle est existante !

En mode projet tu peux démarrer des specs ; alors théoriquement un analyste peut être passé sur la spec fonctionnelle pour donner sa description technique. Dans une bonne partie des cas, le développeur peut lui-même faire l'analyse pendant quelques jours avant, histoire de bien l'implémenter (quel bel anglicisme !). J'ai déjà vu aussi des projets tellement à la bourre que l'on confie directement le cahier des charges...

Je dirai que cela dépend beaucoup donc du projet et de sa gestion. Pour mon expérience, chez un client grosse structure, les développeurs n'avaient qu'à appliquer la recette qu'on leur donnait (j'étais alors analyste, en fait je faisais quasiment du dev sur papier et le donnait à des développeurs). Dans une autre structure, je partais depuis des specs fonctionnelles mais qui avaient un très bon dictionnaire fonctionnel-technique, donc je retombais très facilement sur mes pattes même si je ne connaissais rien au fonctionnel.

Chez un autre client (éditeur de taille moyenne) c'était le dawaa : on m'envoyait une fiche avec juste "le montant machin est mal alimenté", point barre. Quand j'allais voir mon chef de projet, c'était invariablement "Démerde-toi". Sauf quand j'avais de bonnes idées, où on me demandait alors de freiner pour éviter que ce soit trop parfait et qu'il n'y ait plus de maintenance (et même avec mes améliorations c'était looooin d'être parfait ; juste que je pouvais faire passer mon traitement batch en une nuit).

Dans une structure plus modeste (comme là où je suis maintenant) tu peux vite arriver à en faire tout toi-même, depuis l'interview client, ce qui est très intéressant également

Donc tu vois il y a de tout. Mais de manière générale, quand tu arriveras sur le projet, t'inquiètes, on jaugera ton autonomie et on te guidera au cas échéant Si tu postules en SSII, on te placera certainement en mission (et j'espère) avec quelqu'un de ta boîte qui t'aideras à comprendre !

[Nachalnikov]

Salut Titi41,

En tant qu'ingénieur d'études, tu vas développer. C'est donc un mot ronflant pour "développeur" destiné à flatter ton ego.

Envoyé par Titi41

Quelqu'un arrive avec les spécifications, et on code ?

Haha, ça, c'est la théorie. Le fait d'avoir des spécifications dépend du niveau d'organisation du projet où tu interviendras. Sur un gros projet, bien organisé, le client va fournir un cahier des charges et un analyste va "spécifier". La partie "code" arrive ensuite, lorsque le chef de projets puis le client ont validé cette spécification. Sur un projet plus "artisanal", le client va exprimer son besoin à l'oral et le développeur va coder en suivant. Entre les deux, existe une infinité de modèles.

Mais en tant que débutant, ne t'attend pas à avoir des responsabilités. Il faut bien évidemment faire ses preuves avant d'être chef de projets ou analyste. Celui qui confierait ce genre de mission à un parfait débutant serait au mieux un fou, au pire un manipulateur avec des plans tordus derrière la tête. Et enfin, "coder" n'est pas une activité dévalorisante, bien au contraire.

Là, je change de sujet, mais d'une manière générale, on voit que c'est une sorte de Graal auxquels prétendent tous les étudiants frais émoulus : "Chef de Projets"! Leurs "facétieux professeurs" leur ont promis qu'il étaient destinés à régner parce qu'ils sortaient de LA grande école. Or, c'est une blague car vous êtes tous égaux, tous diplômés de Bac+4, Bac+5 et ce n'est pas en fonction de vos diplômes qu'on vous donnera des responsabilités... mais de vos capacités réelles et des opportunités à l'instant T.

[Titi41]

Merci pour ces détails.

Ca ne me rassure pas totalement. Je viens de DUT, j'ai presque 1 an et demi de stage derrière moi, je commence à en avoir assez de faire du code pour du code. J'ai encore BEAUCOUP à apprendre, j'en suis conscient. Mais si on me demande de coder tel ou tel algorithme sans chercher plus à comprendre ou a optimiser, ca va être passionnant..
J’espère que j'aurais un minimum de responsabilités donc.

Et oui Nachalnikov, je suis d'accord avec toi, l'école ne fait pas tout, loin de là.

[Bluedeep]

Envoyé par Nachalnikov

Là, je change de sujet, mais d'une manière générale, on voit que c'est une sorte de Graal auxquels prétendent tous les étudiants frais émoulus : "Chef de Projets"! Leurs "facétieux professeurs" leur ont promis qu'il étaient destinés à régner parce qu'ils sortaient de LA grande école. Or, c'est une blague car vous êtes tous égaux, tous diplômés de Bac+4, Bac+5 et ce n'est pas en fonction de vos diplômes qu'on vous donnera des responsabilités... mais de vos capacités réelles et des opportunités à l'instant T.

Oui, c'est même une évidence démographique car sauf à imaginer une croissance systématique et sans fin de 50% par an du besoin en développeurs, tous les ingénieurs d'études ne peuvent pas devenir CP. (si on compte en moyenne un CP pour 5-6 ingé, et 5 ans pour passer de CP à ingé).

[Nachalnikov]

Salut Titi,

Au risque de vraiment te plomber le moral, c'est encore plus dur avec un DUT. C'est con parce que ton diplôme ne te rend pas moins compétent que tes camarades... mais en France, on est des obsédés du diplôme. J'ai eu des collègues super compétents ayant des BTS; mais pour eux, grimper a toujours été plus difficile. Moi même, après 6 ans d'expériences, on me le sort très souvent (je ne suis pas ingénieur).
J'ai même eu affaire à un guignol qui m'avait demandé si j'avais eu mon bac avec mention... Par chance, il n'a pas osé me demandé ma moyenne en CE1... probablement à cause de ma réaction

Malgré tout, l'horizon n'est pas fermé. C'est juste plus dur. Ça dépendra vraiment des personnes que tu auras en face de toi. Moi, ce sont des clients qui m'ont fait passé chef de projets.

[Titi41]

J'ai fait l'UTC après mon DUT, donc j'ai ce fameux bout de papier qui fait de moi un ingénieur et une meilleure personne sur la grille des salaires

[dev-rennais]

Bonjour,

La majorité des élèves sortant de l'école connaissent ils réellement le rôle de chef de projet ?

Perso, quand je suis sorti de l'école, je répondais à la question :
"Comment vous voyez vous dans 5 ans" et je répondais "j'aimerai monter en compétence rapidement et devenir chef de projet"

Mais quand on voit réellement le rôle d'un CP, je suis pas certain que cela motive beaucoup de monde. Tout du moins la majorité des développeurs que j'ai rencontré n'étaient pas intéressé par cette évolution.

(Propos à nuancer, il s'agit juste de mon observation au qutidien, un CP pourra venir confirmer ou infirmer )
Remplir des tableaux Excel toute la journée.
Passer du temps en réunion.
Se faire taper sur les doigts par le client.
Faire le tour de table pour vérifier l'avancement.

C'est un boulot stressant, voir peut être plus stressant que celui du développeur car le CP dépend uniquement des dires des développeurs pour estimer la charge et l'annoncer au client. Donc si le développeur se plante dans son estimation, c'est au CP de l'annoncer au client. Bref pour avoir discuter avec mes anciens CP, j'ai vite relativisé sur ma condition.

Sinon pour apporter une précision en plus, le terme de "Ingénieur d'étude ..." est pour moi totalement bidon. Il s'agit juste d'une étiquette que l'on attribut pour te vendre plus cher au client. J'ai un bac+3 et j'ai été embauché en tant qu'ingénieur d'étude (sans la paie malheureusement). Mes collègues pensaient tous que j'avais un bac+5 (Attention je remets pas au cause le diplôme, mais l'utilisation de l’appellation en SSII)

Mais concrètement oui tu fera en majorité du développement.

En SSII il y a deux types de missions
- TMA
- Forfrait

corrigez moi si je me trompe

En TMA tu va faire de la maintenance applicative.
Tu arrives sur un projet déjà bien entamé (3-4 ans).
Ce projet à un lot d’anomalies à corriger.
On te passe la doc, les spécifications, et hop à toi de faire en sorte de corriger l’anomalie.

Au Forfait (pas encore eu l'expérience)
Mais je crois que cela se rapproche plus de l'édition.
Ta boite à gagné un marché et du coup tu développes l'application de A à Z.
Mais généralement il y a un architecte qui est passé avant toi pour mettre en place la structure de l'application et définir les frameworks à utiliser.

Dans tous les cas tu fera en majorité du développement.
Mais si tu as de la chance, tu pourra tomber sur un projet où la notion de tests, performance auront un sens, et la ton développement gagnera en intérêt.

Tu fera forcément un peu d'analyse, car il te faudra comprendre la structure de l'application pour effectuer tes correctifs.

bon j'espère avoir apporté quelques info supplémentaires, voir confirmé ce qui a déjà été dit.

cordialement

[Nachalnikov]

Bon Titi, alors tant mieux pour toi. Il ne te reste plus qu'à montrer que tu en es capable

Dev-rennais, oui, tu as bien perçu le quotidien de beaucoup de chefs de projets. Mais il ne tient qu'à eux d'en faire autre chose. En tant que chef de projets, tu peux être un référent technique pour ton équipe, un pédagogue qui leur apprend les bonnes pratiques et un tuteur pour faire évoluer les meilleurs dans la direction qui leur convient. Je suis très heureux quand mes anciens collègues me contactent pour des conseils sur leur évolution de carrière ou simplement pour me tenir informé.
Tu peux aussi être un référent important de ton client qui sait qu'il peut compter sur toi. Ça ne te sauvera pas des coups de triques en cas de dépassements mais ça atténuera leur force.

Sinon pour les types de missions, tu peux ajouter la régie pure et simple (tu renforces un SI client) et les "pôles de compétences"(régie ou forfait) où une équipe de prestas réalisent un projet chez le client.

[Bluedeep]

Envoyé par dev-rennais

En SSII il y a deux types de missions
- TMA
- Forfrait

corrigez moi si je me trompe

En TMA tu va faire de la maintenance applicative.

Ben, tu oublies la régie classique sur un projet en démarrage qui est sans doute le plus intéressant : les contraintes du forfait empêche souvent de prendre des voies techniquies "exploratoires", alors que sur un projet démarrant ex-nihilo, on a toute la phase de "POC" qui peut être intéressante, avec souvent un peu d'archi technique à faire (suivant la taille de l'équipe).

C'est là qu'on détecte les dev "inventifs".

[Robin56]

Envoyé par Titi41

J’espère que j'aurais un minimum de responsabilités donc.

Je comprends tes craintes mais en même temps, il y a quelque chose que l'école nous apprend que trop peu : être humble.
- En sortant de l'université ou de n'importe quelle école d'ingénieur, on ne devient pas chef comme ça.
- En sortant d'école, on n'a vraiment pas fais le tour du développement.

Comme le dis dev-rennais, grâce à nos études nous sortons tous en disant la chose suivante (ou s'en approchant) :

- Qu'est ce que vous voulez faire plus tard ?
- Eh bien 2 ans de dev et après je passe chef de projet...

Plusieurs bémols à apporter à ça :
- Être CDP n'est vraiment pas de tout repos (je ne le suis pas mais j'en côtoie). L'intitulé "chef" n'est pas toujours une récompense suffisante vu le stress engendré (cf. post dev-rennais).
- Être développeur n'est pas comparable aux projets/stages durant les études. Les phases d'analyse, de tests, de conception, d'architecture, d'avant-vente parfois, de maintenance, ... tout ces aspects prennent une autre envergure voir sont une totale découverte.
- Entre la case développeur débutant et chef de projet, il y a de la place. Un développeur ayant plus d'expérience que toi ne va pas pour autant faire du code pour du code. Il va être force de proposition, il va prendre part aux discussions en amont de projet (en terme d'archi., de besoin, de conception), il pourra prendre part aux nouveaux contrats, ...

Je préférais juste clarifier les choses grâce à cette explication qui fera surement donneur de leçon pour certains (mais ce n'est pas le but). En tout cas, jeune employé, j'ai trouvé qu'à partir du moment où l'entreprise connaissait ta valeur, la responsabilité (aussi minime soit-elle) vient assez vite (liberté d'organisation, la force de proposition sur l'évolution d'une application, rédaction de propal, place de référent technique sur certains projets, ...).

[Glutinus]

"Chef de projet" est l'évolution que voudrait systématiquement toute SSII, comme si c'était l'aboutissement d'une carrière. Quand je passais des entretiens, on me disait souvent "Vous serez chef de projet dans 5 ans", ce à quoi je rétorquais que je préférais être analyste et à terme faire dans l'AMOA. Ce à quoi on me répondait que ça marchait aussi Mais je pense que c'est la bonne réponse à donner, polie et entendue, et c'est une fois sur les rails qu'on dit ce qu'on veut vraiment faire (rester développeur, expert, commercial, etc.)

On peut être aussi chef d'une minuscule équipe, ou chef de soi-même

Titi41 : partout dans le monde du travail, les gens débutent, les gens peinent, mais tout le monde survit, tu vas pas te suicider après un an (euh, fuis france telecom sinon ) !
Alors ce sera pas très facile mais c'est loin d'être une montagne à escalader (enfin je continue à prétendre que tu pourras être envoyé dans une équipe composée de gens de ta boîte, et donc ils te "protègeront").

Quand j'étais en stage, j'avais un chef qui m'a dit "On ne t'en voudra jamais de ne pas réussir quelque chose ; on t'en voudra par contre de ne pas t'être donné les moyens ni d'avoir averti suffisamment tôt que tu étais en galère". Souviens-toi juste de ça
(se donner les moyens = en avoir parlé aux collègues, poser des questions même sur des choses que l'on a faite dix fois pour être sûr...)

[Robin56]

Envoyé par Bluedeep

Ben, tu oublies la régie classique sur un projet en démarrage qui est sans doute le plus intéressant : les contraintes du forfait empêche souvent de prendre des voies techniquies "exploratoires", alors que sur un projet démarrant ex-nihilo, on a toute la phase de "POC" qui peut être intéressante, avec souvent un peu d'archi technique à faire (suivant la taille de l'équipe).

C'est là qu'on détecte les dev "inventifs".

L'interco de 1 mois avec un projet dans les rails en prévision 1 mois plus tard permet aussi d'approcher ce système

Envoyé par Glutinus

On ne t'en voudra jamais de ne pas réussir quelque chose ; on t'en voudra par contre de ne pas t'être donné les moyens ni d'avoir averti suffisamment tôt que tu étais en galère

Ca c'est bien vrai. En fait on te reprochera plus facilement ta faculté à échanger/avertir/prévenir que ta vraie capacité technique à résoudre le problème. Car bon si tu bloques vraiment sur quelque chose, il y a des développeurs/architecte avec l'expérience qui te trouveront ton soucis en 2 minutes là où tu auras galéré 2 heures.

[Titi41]

Envoyé par Robin56

Je comprends tes craintes mais en même temps, il y a quelque chose que l'école nous apprend que trop peu : être humble.
- En sortant de l'université ou de n'importe quelle école d'ingénieur, on ne devient pas chef comme ça.
- En sortant d'école, on n'a vraiment pas fais le tour du développement.

Je le sais très bien et je n'aspire pas à un poste de chef de projet dès la sortie de l'école. J'ai pris conscience de ca il n'y a pas si longtemps, mais maintenant, j'ai compris !

Envoyé par Robin56

Comme le dis dev-rennais, grâce à nos études nous sortons tous en disant la chose suivante (ou s'en approchant) :

Plusieurs bémols à apporter à ça :
- Être CDP n'est vraiment pas de tout repos (je ne le suis pas mais j'en côtoie). L'intitulé "chef" n'est pas toujours une récompense suffisante vu le stress engendré (cf. post dev-rennais).

Je pense aussi être au courant des idées reçues sur le poste de chef de projet. Je sais que ce n'est pas de tout repos et tout ca.

Envoyé par Robin56

- Être développeur n'est pas comparable aux projets/stages durant les études. Les phases d'analyse, de tests, de conception, d'architecture, d'avant-vente parfois, de maintenance, ... tout ces aspects prennent une autre envergure voir sont une totale découverte.
- Entre la case développeur débutant et chef de projet, il y a de la place. Un développeur ayant plus d'expérience que toi ne va pas pour autant faire du code pour du code. Il va être force de proposition, il va prendre part aux discussions en amont de projet (en terme d'archi., de besoin, de conception), il pourra prendre part aux nouveaux contrats, ...

Je préférais juste clarifier les choses grâce à cette explication qui fera surement donneur de leçon pour certains (mais ce n'est pas le but). En tout cas, jeune employé, j'ai trouvé qu'à partir du moment où l'entreprise connaissait ta valeur, la responsabilité (aussi minime soit-elle) vient assez vite (liberté d'organisation, la force de proposition sur l'évolution d'une application, rédaction de propal, place de référent technique sur certains projets, ...).

C'était mon interrogation initiale.
Je verrai bien quand je travaillerai...
Merci pour vos commentaires en tous cas.

[Robin56]

Envoyé par Titi41

C'était mon interrogation initiale.
Je verrai bien quand je travaillerai...
Merci pour vos commentaires en tous cas.

J'irais même plus loin que ce que j'ai dis concernant les responsabilités.

En arrivant sur le marché du travail, tu arrives avec le titre "ingénieur débutant" et le coût minimum qui va avec. Donc à partir du moment où tu as fais tes preuves, ton chef de projet (ou alors le suivant) n'hésitera pas à charger la mule (c'est toi ^^). Car bon dans sa liste de coût, tu es bien meilleure marché qu'un architecte ou un développeur plus expérimenté. Je caricature un peu mais pas tant que ça.

[Bluedeep]

Envoyé par Robin56

L'interco de 1 mois avec un projet dans les rails en prévision 1 mois plus tard permet aussi d'approcher ce système

Tu affectes budgétairement ce genre de truc comment ?

[Robin56]

Envoyé par Bluedeep

Tu affectes budgétairement ce genre de truc comment ?

Ah oui budgétairement parlant par contre, je me demande si c'est très légal. C'est de l'arrangement interne en considérant que tu fais de la R&D/veille techno.

[Bluedeep]

Envoyé par Robin56

Ah oui budgétairement parlant par contre, je me demande si c'est très légal. C'est de l'arrangement interne en considérant que tu fais de la R&D/veille techno.

De l'arrangement interne ? j'avoue ne pas comprendre. Ton client ne va pas te payer avant le début du contrat. Et travailler sur des POC ou sur une archi en l'absence de SFD c'est un peu essayer d'atteindre une cible dans le noir.