Chers toutes et tous
 
Je m'adresse à vous aujoud'hui dans le but d'avoir des informations, conseils qui pourrainet m'aider car je ne sais vraiment pas à qui m'adresser
 
Je suis en stage de fin d'étude (bac+5) d'une école d'ingé de réputation correcte et j'tudie l'informatique
la formation que j'ai reçue est orientée technique ce qui fait que je suis actuellement un stagiaire consultant technique
 
j'ai regardé des offres d'emplois dans des cabinets de conseil et j'ai bien vu que les profils fonctionnels ne sont réservés qu'à des gens sortant de grandes écoles telles que l'ENSAM, centrale (en effet, ces entreprises disent ne recruter que dans des grandes écoles et pour les profils techniques, c'est MIAGE? écoles comme la mienne...)
 
par ailleurs, je connais des personnes sortant de mon école qui ont réussi à faire leurs preuves dans le fonctionnel (c'est-à-dire qu'elles ont été recrutées et s'en sortent très bien)
 
je voulais savoir si moi aussi je peux teneter ma chance en sortant de l'école directement vers ce genre de travail
 
ou si j'aurai plus de chances en complétant ma formation par un master ou un diplme plus fonctionnel
 
je n'i aucune idée de comment procéder , mais ce que je sais c'est que je n'ai pas envi d'attendre 5 ou 6 ans avant de migrer vers le fonctionnel (car avec de l'expérience on fait de moins en moins de techniqe et de plus en plus de fonctionnel)
 
merci beaucoup pour votre aide

up

hmm je vois ce que vous voulez dire
oui je me suis peut etre mal exprimé
en ce moment, en tant que consultant technique j'interviens dans la phase de mise en place du SI, déploiement, paramétrage, développement
et ceci du à ma formation
maitenant je voudrai pouvoir intervenir en phase amont, expression du besoin rédaction du cahier des charges....ce que fait un stagiaire sorti d'une grande école
 
je connais certains JD qui sont dans la MOA et non pas dans la MOE alors qu'ils sortent de la meme ecole que moi
 
je voudrai savoir comment je peux maximiser mes chances moi aussi

merci pour la réponse, je sais que même au sein de ma formation, ça parait louche et pas-très-interessant comme choix donc c'est vraiement difficile de parler et d'avoir des infos
 
selon toi c'est chez le "client final" que j'ai plus de chances de faire ça?
comme tu dis ça doit pas être facile d'etre directement chez le client final, et je ne connais pas de cas de JD dans cette situation
la plupart sont dans les SSII , cabinets de conseil
certains, dans les cabinets de conseil font de la MOA
et d'autres du dév
alors que en SSII d'après ce que j'ai vu il faut attendre pas mal d'années avant de ne plus faire que du dév
 
mais le fait est que c'est ce que je veux faire, et je voudrai vraiment me retrouver dedans après avoir été diplomé

merci  
cela me donne deja beaucoup d'informations sur comment je dois m'orienter au cours de mon dernier mois de stage et dans quelles entreprises je dois postuler
 
mais les consultants en MOA alors dans les "petits" cabinets de conseil basés à Paris , d'apres ce qu'un d'entre eux m'a dit il ne fait pas dutout de dév  
je ne peux pas tenter dans un cabinet de conseil?

post double: j'ai un peu regardé les offres d'emploi en test qualification recette et apparamment c'est après quelques d'années d'éxperience (ce qui est plutot logique) que on peut accéder à ce type de poste ...

ouai mais en meme temps, meme si ils ont pas la crédibilité immédiate et l'experience du terrain ces chefs de projets je pense sont spécialement formés à ces fonctions dans leur école
je sais qu'une personne ayant fait de l'info à l'ENSAM ne fera pas dutout la meme chose que une personne sortant d'une ecole de groupe B et qui fait aussi de l'info
 
peut etre que c'est moi qui ai trop la grosse tete ou pas la tete sur les epaules et trop d'ambitions au niveau où je suis et que pour bien me former je dois passer par la dév....

oui j'avoue , je ne dirai pas le contraire
en tous cas, ta vision m'aura permis de voir la réalité des choses ...

Voici un lien très intéressant qui aidera peut-être certains à bien faire la distinction entre vision technique (!= développement) et vision fonctionnelle (pas de développement mais solides bases techniques indispensables, contrairement à ce que certains pensent) : Informatique - Consultant Fonctionnel [APEC]
 
Le système d'information peut être vu selon trois vues : la vue métier, la vue fonctionnelle et la vue informatique.  
La dernière se divise elle-même en une vue applicative et une vue sur l'infrastructure. Ce que décrit bibifoc7 (partie sur l'informaticien) se situe typiquement au niveau applications et conception, là où les compétences en développement sont effectivement indispensables. Par contre, il convient de bien faire la distinction entre les adjectifs "technique" et "fonctionnel", une dualité que l'on retrouve sur plusieurs aspects : conception technique / conception fonctionnelle, spécifications techniques / spécifications fonctionnelles, consultant technique / fonctionnel, etc.  
 
Par exemple, la conception technique est uniquement destinée aux équipes de développement alors que la conception fonctionnelle représente l'interface entre les équipes de développement et les clients finaux, la MOA, les sponsors, etc. L'analogie est la même entre les notions de spécifications techniques (destinées aux développeurs, architectes, et plus largement à un public technique) et de spécifications fonctionnelles (à valider par le client).  
 
xerox888, pour tenter de répondre à tes interrogations, non le monde du fonctionnel n'est pas réservé aux étudiants des grandes écoles. Par contre, je ne sais pas jusqu'à quel niveau d'abstraction tu souhaites monter,  mais tu valoriserais fortement ton profil en complétant ta formation avec un diplôme en management dans le domaine des SI. Ce type de formation te donnera une vision large sur tout ce qui tourne autour du SI (aspects fonctionnels, enjeux stratégiques, audit, architecture d'entreprise, etc.).
 
A retenir (non pas pour xerox888 mais pour ceux qui n'ont pas les pieds sur Terre) :
 

Regarde le programme d'une école qui forme aux masters type Management et Technologies de l'Information.
Il y a de forte chance que dans ton cursus il y ait eu des cours similaires.
Ce qui peut t'apporter un plus ça va être la partie management (budget, planning, projet, RH...)
Comme le souligne C-O, une année supplémentaires pour obtenir ce master, par ex, peut être utile... si tu n'as pas assez confiance en tes capacités (je ne connais pas ton cursus).
 
Les certifications en gestion de projet, pour un JD seront un fort plus:
- La gestion de projet: certif AFITEP (IPMA/ICEC)
- Du fonctionnel: l'ITIL (c'est du fonctionnel intra service info)
- Regarde aussi CMMI
 
Ensuite concernant ce qui a été écrit:
- Il faut arréter de croire que les postes à responsabilités sont réservés aux sortants de grandes écoles et que les miettes sont pour les autres. Il n'y a pas que Airbus qui recrute!
Et ceux qui se prennent pour Airbus, par leurs exigences de recrutements, sont souvent déçu  
 
- Un chef de projet à pour rôle, comme son nom l'indique, de conduire un projet.
Ce n'est pas un "pur" technique, l'expertise technique n'est pas son métier.  
Il doit être capable (je simplifie) de gerer un budet, des ressources, respecter les planning, faire l'interface entre les équipes techniques et métier... Il n'a absolument pas besoin d'être un cador de l'info, c'est à son équipe de l'être.
 
- Pour faire du fonctionnel, tu as encore moins besoin d'être un as de la technique puisque ton métier (je simplifie la aussi) est un premier lieu d'être capable d'exprimer un besoin métier en fonction de leur process (voir les améliorer). Là, c'est la connaissance d'un milieu (finance/banque, industriel, pharma...) qu'il faut privilégier.
 
Et l'informatique ne se limite pas au developpement. Il y a l'intégration d'ERP/EAI, les infra systèmes, les infra réseau, les télécoms etc etc...

c'est sa maitrise de la "gestion de projet" qui est à remettre en cause et non ses connaissances techniques purement logiciel (sort un peu de ta bulle dev logiciel).
 
Je vais prendre un exemple tout simple pour que tu puisses comprendre:
Imaginons un EAI à mettre en place. Cette entreprise est en plus répartie sur plusieurs sites distincts.
Ca veut dire que ton chef de projet doit connaitre le developpement logiciel, les infrastructures réseau, télécom et systèmes, sans parler de l'EAI lui même, des protocoles de communication ou des métiers tout court?
Les moutons à 5 pattes n'existent pas, chacun son metier. Le chef de projet, peut être assimiler à un chef d'orchestre qui doit connaitre sa partition et comment mener son orchestre et non savoir jouer de chaque instrument.

En effet, pris à la lettre, mon exemple n'est pas le meilleur choisi, mais dans l'idée le concept correspond assez bien.
Mais pour quelqu'un qui fait du fonctionnel et donc doit avoir un certain niveau d'abstraction, tu restes bien terre à terre (je taquine, il ne faut pas le prendre au 1er degré).
 
J'ai aussi plusieurs années en technique, et ensuite (en reprise d'étude) suivi un cursus en management de SI.
Et je persiste, ce sont deux métiers différents. D'ailleurs dans les master en management, le technique ne représente qu'1/3 de la formation... le reste c'est du management.
 
Tu es dans le developpement et tu as peut être cette vision à cause des méthodes agiles (type Xtreme programming, scrum ...) ou le rôle du chef de projet disparait pour faire place au coordinateur d'équipe (parfois appelé scrumaster)... mais ce n'est pas toujours le cas et le chef de projet rejoint ce que je dis plus bas.
En effet dans ce cas là il faut être un technique avec des compétences en gestion de projet.
 
Mais l'informatique ne se limite pas au dev et aux méthodes agiles.
Par contre, et ça rejoint un peu les méthodes agiles, le chef de projet du 21eme siècle (désolé pour le terme, je ne savais pas comment présenter ça) et l’équipe définissent le plan d’action.  
L’équipe (dont le chef de projet) décide de ce qui est faisable et de ce qui ne l’est pas... et le chef de projet tranche (ensuite il y a toute la partie gestion de projet, interraction avec les parties prenantes...).
Dans ce cas là, le management participatif, le coté technique n'est pas important pour le chef de projet. C'est sa capacité à manager qui importe puisque les choix et dispositions techniques sont définis au sein de l'équipe.
C'est différent de la méthode à la papa ou le chef de projet etait le "grand manitou" et où les méthodes de management de projet (et certaines de leurs dérives, dont tu parles) n'ont plus rien à voir avec ce qui se pratique de + en +.
Et pour finir, les bons techniciens ne font pas forcement de bon manager (dans le sens management de projet) et les projets en souffre alors qu'un bon manager (toujours dans le sens management de projet) même faible techniquement à toujours de bons résultats de projets.
 
Voila: je n'ai pas la prétention de vouloir te faire changer d'avis, chacun tire les leçons de son vécu, mais Xerox888 aura les 2 avis pour se faire sa propre opinion.

(Désolé pour l'aparté)
 
Je ne sors pas ces expressions de ma poche:
Scrum et XP (extreme programming)
 
Sur google, j'ai tapé offre emploi + méthodes agiles, et voila ce que j'ai trouvé sur la 1ere page:
- 1
- 2
- 3
 
Ces méthodes commencent à arriver en France et donnent d'excellents résultats outre-atlantique d'où leur entrée en force.  
Rien à voir avec une branche d'activité ou secteur. Peu utilisé car peu connu tout simplement.
J'ai connu ces méthodes aux travers de ma formation de management (récente) et non de ma formation technique (plus ancienne il est vrai). Mais perso je laisse tomber le dev auquel je préfère l'intégration donc j'aurai abandonné avant d'avoir maitrisé le sujet. Mais ces méthodes sont l'avenir du génie logiciel (c'est mon avis).
 
EDIT: ça prend "tellement d'ampleur" que depuis quelques années (3 ou 4) aux US les boites (je crois que c'est Google qui a lancé le truc) engagent des promo entières pour bosser ensemble sur des projets; en France il me semble que c'est Capgemini qui part dans cette voie (embauche de promo entière formées à ces nouvelles méthodes de dev).
 
(fin d'aparté)
 
C'est la réduction des budgets, des délais de dev et des dérives en temps et budget de dev (ainsi que de nombreux abandons : de l'ordre de 20-25% je crois) qui ont conduit à ces méthodes et à une redéfinition du rôle de chef de projet. Il n'y a qu'à regarder le contenu des offres d'emploi concernant les profils de chef de projet certifié PMP ou IPMA.
 
Mais bon, on tourne en rond.  
On est pas d'accord sur le fond (et je respecte ton point de vue, comme je disais chacun son expérience... bien qu'il ne faille pas faire d'empirisme), je ne pense pas qu'il soit utile de continuer cette polémique.

En effet oui... Tu vois, tu commence à y venir

L'idée est de faire bosser en parallèle des équipes techniques et des équipes fonctionnelles. Les équipes fonctionnelles vont recueillir l'ensemble des besoins des utilisateurs et fixer des règles de gestion permettant de faire évoluer le SI selon une certain trajectoire et d'atteindre une cible technique, fonctionnelle, ou les deux. Ce découpage est obligatoire dans le cas de projets importants mais il me semble peu crédible de placer des gens qui n'ont pas un bagage technique conséquent à des postes fonctionnels. Lorsque c'est le cas, on voit des gens qui brassent du vent, qui ne sont pas conscient des conséquences sous-jacentes des choix effectués (du point du vue technique ou humain), ou pire encore, de mauvaise fois lorsqu'on tente de leur expliquer qu'ils orientent mal leur réflexion.
 
En ce qui concerne Scrum et Extreme Programming, ce sont plus des processus de développement que des méthodes de développement dans la mesure où ils ne font que fournir un ensemble d'activités permettant de parvenir à un résultat. Bien qu'ils fournissent une "boite à outils", ou artefacts, ils n'expliquent pas comment parvenir à ce résultat (l'inverse aurait été assez étonnant). Vu de façon synthétique, Scrum et Extreme Programming ont pour motivation d'éviter les développements sous la forme d'effets tunnel, de démarrer rapidement les développements et de se focaliser sur la motivation des équipes. Pour recouper avec ce qu'on disait plus haut, on a un peu du mal à voir où est la place du fonctionnel (de mémoire, ce rôle est réparti entre les différents acteurs techniques) dans ce type de processus qui cible essentiellement les petites équipes.

Je crois que le problème de cette discussion et sur ce point (en italique).
Depuis le debut on parle chef de projet qui doit être technique ou non...
 
Dans un projet on peut distinguer 3 pôles (je vais essayer de faire court):
- La maitrise d'ouvrage
- La maitrise d'oeuvre  
- Le réalisateur (celui qui fait: l'ensemble des dev - je reste la dessus car il y a certain bloquage)
Pour chacun des pôles il y a un chef de projet.
 
Il n'y a vraiment que dans le dernier pôle (la réalisation) où le chef de projet doit être technique, mais pour les 2 autres il n'y a pas d'intéret puisque :
- Le rôle du 1er, maitrise d'ouvrage, (celui qui paye et lance le projet) le but est d'exprimer le besoin.
- Le rôle du 2nd, maitrise d'oeuvre, c'est de trouver les réalisateurs et piloter le projet( piloter: project management), et faire l'interface entre le 1er et le 3eme.
Car dans un projet, il n'y a pas qu'un seul réalisateur d'où la nécessité d'un maitre d'oeuvre.
 
Alors dans le cas de la réalisation, oui le chef de projet doit être un tech. Dans la maitrise d'ouvrage et d'oeuvre, ce n'est pas nécessaire. Pour la maitrise d'ouvrage il faut que la personne est une très bonne vision métier (purement fonctionnel/processus) pour exprimer clairement son besoin et si nécessaire optimiser les processu métiers.  
Pour la maitrise d'oeuvre il faut que la personne soit un bon gestionnaire de projet.
Mélanger les 3 fonctions au seins d'une même équipe fait généralement capoter un projet : on est demandeur, on pilote et on réalise ... c'est être juge et partie.
Mélanger les 2 dernières fonctions devient risqué dans les projets commençant à prendre de l'envergure.
 
Je pense que depuis le début vous vous placiez du coté "réalisateur" alors que moi j'étais coté maitrise d'ouvrage et d'oeuvre.
Maintenant si c'est pour me dire que coté maitrise d'ouvrage et maitrise d'oeuvre il faut un chef de projet technique... je vous renvoie à des lectures sur la gestion de projet.
 
 
Sinon, les méthodes agiles étaient juste une aparté, je voulais pas fair débat ladessus.  
Concernant le scrum, c'est bien une méthodes de management de projet (et non un processus de dev).  
L'XP est en effet plus une méthodologie d'ingénierie (je n'aurai pas du en parler, même s'il y a du management de projet).
Pour le scum: bien qu'à l'origine conçu pour le dev logiciel, cette méthode peut être utilisé dans n'importe quel environnement (et pas seulement à l'info)... j'en utilise qqls principes dans un domaine non logiciel.
Ce n'est absolument pas réservé à de petites équipes: mais on fragmente le projet en petite équipe (c'est différent).
Une fois encore, ne pas se limiter au dev logiciel, il n'y a pas que ça dans l'info.

C'est de la théorie pour ceux qui n'appliquent pas ces méthodes.
Je pense tout simplement que tu ne discernes pas les rôles de la maitrise d'ouvrage et de la maitrise d'oeuvre. Et donc tu fais un amalgame dans la répartition des rôles et pouvoir entre MOA et MOE... erreur classique dans la gestion de projet.  
C'est un travers que l'on rencontre souvent avec de pur technique qui passe au management de projet sans préparation (ou formation) aux méthodes du management... J'ai été dans ce cas: dont les remarques completements idiotes du style: c'est de la théorie, en pratique (sous entendu: dans la vrai vie) on peut pas l'appliquer.  
Eh ben si, on peut l'appliquer, mais il faut s'éduquer au management de projet (par la formation).  
 
J'ai récupérer ça sur un site, qui résume les rôles MOA/MOE dans un projet info:
"Le rôle du MOA consiste à évaluer avec les utilisateurs leurs besoins, établir un cahier des charges, assurer le lien avec le service informatique, contrôler le planning de réalisation produit par la MOE et de faire du reporting pour indiquer les retards éventuels.  
La MOE se charge de voir quels moyens techniques elle met en face du cahier des charges, si elle a les compétences en interne..."

Si tu penses à SCRUM ou XP en parlant de "ces méthodes", sache que celles-ci ne sont en aucun cas généralisées en France.  
 
Pour les histoires de MOA, MOE & cie, je vous invite à consulter le site de Michel Volle, l'une des références en France : Rôle de la maîtrise d’ouvrage, Maîtrise d'ouvrage et maîtrise d'oeuvre, etc.
 

 
Le management de projet, c'est large et les visions peuvent être très différentes d'un manager à un autre.
 

Une référence mondiale : http://www.controlchaos.com/
Connais-tu MERISE ? Si c'est le cas, je pense que tu saisiras la nuance. SCRUM n'impose pas d'artefacts.

la discussion est devenue plus qu'interessante grace à vos participations respectives
merci  
je vais lire en détail chacun de vos input
excusez moi j'ai eu quelques problèmes qui m'ont empeché d'intervenir sur ma propre discussion lol