Tous droits réservés

Interview : Rencontre avec nohar

Que fait un ingénieur R&D ? Et c'est quoi la R&D ? nohar nous éclaire...

Dernière mise à jour :
Auteurs :
Catégories :

Aujourd'hui nous allons discuter avec nohar, ingénieur R&D.

Salut Nohar et bienvenue dans mon presse-agrumes ! Alors comme ça tu es ingénieur R&D ? Ça signifie quoi un peu plus concrètement ?

Salut !

Alors pour commencer, R&D signifie Recherche et Développement. Comme on peut s'y attendre, c'est un domaine à cheval entre deux mondes opposés. D'un côté, nous avons le monde de la recherche, où l'on prend le temps d'explorer à fond le moindre détail de façon à construire des connaissances sur lesquelles la science peut continuer à progresser. De l'autre, nous avons l'ingénierie qui consiste à assembler des briques technologiques entre elles pour développer des projets novateurs, avec diverses contraintes à respecter (budget, temps, performances, stabilité, sécurité…). De but en blanc, comme ça, je veux bien croire qu'on ait du mal à voir à quoi ressemble la rencontre des deux, et surtout à quoi elle peut servir !

Lorsque l'on élabore un projet ou une nouvelle fonctionnalité sur un système, il n'est pas rare que certains éléments nous échappent, pour lesquels on se demande comment on va bien pouvoir réussir à faire ce truc. Ces éléments inconnus, on les appelle des verrous techniques. Mon métier, c'est de m'occuper de ces verrous :

  • En réalisant des études de faisabilité pour déterminer ce qu'il est possible de faire avec les ressources qu'on a à notre disposition ;
  • En évaluant les risques associés, pour caractériser les difficultés auxquelles on peut s'attendre ;
  • En proposant, quand c'est possible, plusieurs alternatives techniques au chef de projet pour qu'il choisisse la voie qu'il veut prendre.

Ensuite vient la partie développement. Une fois qu'on a décidé de suivre une piste donnée, je peux développer un prototype, ou bien directement un module qui réalise la tâche voulue. Enfin, je m'occupe de documenter tout ce bazar, pour ne pas être le seul à comprendre comment ça fonctionne et que d'autres développeurs puissent prendre le relai et maintenir le code derrière moi.

En somme, l'ingénieur R&D, c'est celui sur qui on repose pour gérer ce que l'on ne connaît pas encore à l'instant T dans un projet de développement. Et parfois, en effet, ça demande de dépiauter l'état de l'art de la recherche scientifique pour faire un rapport le plus solide possible ou tout simplement trouver la bonne approche.

Enfin ça, c'est sur le papier…

Dans la pratique, étant donné que je travaille dans une toute petite structure, les contours de mon poste sont beaucoup plus flous que ça. En réalité, même si je travaille la plupart du temps sur la conception de nouvelles fonctionnalités pour les systèmes que vend ma boîte, il m'est arrivé d'intervenir sur toutes les phases de ces projets, y compris le déploiement, et même de me déplacer chez les clients pour faire du support technique ou encore de dispenser des formations. C'est ça la magie des startups. ;)

Peux-tu nous en dire un peu plus sur ton quotidien ?

Dans les faits, mes journées ressemblent beaucoup à celles de n'importe quel développeur : j'arrive, je prends un café, et je dépile des tickets sur notre outil de gestion de projet. :)

Ce qui change, c'est souvent la nature de ces tickets. Comme je l'ai dit plus haut, je traite le plus souvent des nouvelles fonctionnalités pour dont je dois d'abord déterminer la faisabilité, ce qu'il est possible de réaliser et en combien de temps. Dans le jargon, on appelle ça du dérisquage et la façon dont je vais m'y prendre dépend de la nature de la fonctionnalité, bien qu'on puisse dégager une méthode globale :

  • Recherche bibliographique. Y a-t-il des publications scientifiques sur le sujet ? Qu'en disent-elles ? Cette phase est souvent optionnelle, mais elle devient indispensable quand le sujet sort du domaine d'expertise de l'entreprise.

  • Documentation technique. De quoi sont capables les bibliothèques que nous utilisons déjà ? Y'en a-t-il d'autres ? Comment marchent-elles ? Qu'ont-elles de particulier ?

  • Prototypage. C'est l'étape que je préfère. Souvent, ça consiste à produire du code qui réalise la tâche voulue et jouer avec. Dans la réalité, les prototypes sont souvent repris tels quels et intégrés au système moyennant quelques retouches.

Évidemment, quand on se trouve dans des périodes moins denses en R&D, par exemple juste avant de boucler une version mineure d'un système, je dépile aussi pas mal de tickets de type bugfix, pour donner un coup de main sur la stabilisation du logiciel.

En dehors de ces tickets à traiter, mes journées comportent, comme pour tous les ingénieurs, leur lot de communication, de réunions auxquelles il faut participer et de documents à rédiger. De ce point de vue, j'ai la chance de travailler en amont du projet avec un rôle qui ne nécessite pratiquement aucune interaction avec des fournisseurs ou des clients : mes interlocuteurs privilégiés sont les autres ingénieurs de mon équipe et ma hiérarchie. Ça me laisse pas mal de temps pour travailler en autonomie, et c'est quelque chose que j'apprécie.

Et pourquoi en es-tu arrivé là ? Qu'est-ce qui t'a attiré dans ce métier ?

La raison principale, je suppose, c'est que je préfère travailler en amont des projets, quand il faut tout inventer, tout imaginer, tout décider. Dans le cycle de vie de n'importe quel projet, c'est la période où l'on a le plus de champ libre. Ensuite, il y a le fait que dans notre culture, quand on veut faire carrière dans l'informatique, on se place souvent une sorte de frontière mentale entre l'expertise technique et le management : quand on discute perspectives d'avenir avec des gens des ressources humaines, on ressent pas mal ce clivage, et en ce qui me concerne, je préfère devenir un référent technique, travailler sur des projets de plus en plus pointus et tendre vers la maîtrise de mon sujet, que vers le management de personnes ou de projets.

En fait, c'est la voie rêvée pour garder le plus longtemps possible les mains dans le cambouis. :D

Il y a également le fait que ce soit un challenge perpétuel : la description du poste, c'est quand même trouver comment faire tout ce qu'on ne connaît pas à l'instant T, donc se frotter perpétuellement à des domaines, algorithmes, techniques, outils… inconnus. C'est particulièrement excitant, et l'intérêt pour ce qu'on fait est donc sans cesse renouvelé.

En termes d’études, les voies sont nombreuses ou ton parcours a joué une part importante ?

Euh… Les deux, mon capitaine !

Je ne crois pas qu'il y ait un parcours type pour faire de la R&D, surtout dans une petite structure. Je pense qu'à peu près n'importe quelles études niveau ingénieur (donc bac+5, mais pas nécessairement une école d'ingénieur) en informatique font l'affaire.

En revanche, je crois que mon parcours m'a poussé naturellement vers ce métier. J'ai d'abord fait une prépa généraliste (de laquelle je garde des souvenirs qui, quoique excellents, ne sont pas spécialement studieux 1), puis j'ai intégré une école d'ingénieurs où, à mon grand dam, j'ai découvert que l'accent, en termes de formation, était mis sur la communication et le management plutôt que la technique à proprement parler2.

Deux ans plus tard, je décidai de quitter cette école pour aller faire un master de recherche en informatique à l'université, avec comme spécialité la vision par ordinateur, et pour la première fois dans mes études, je me suis senti dans mon élément.

Une fois mon master en poche, j'ai commencé à travailler pour une petite structure comme ingénieur en R&D, puis je me suis peu à peu éloigné de mon domaine d'études (la vision) pour m'orienter vers d'autres paysages techniques (en l'occurrence, actuellement, les réseaux et la cyberdéfense).

Penses-tu que n'importe qui peut faire ce genre de travail ou faut-il certaines dispositions ?

Tel que je vois mon poste aujourd'hui, il me semble inconcevable de le considérer comme un "job alimentaire". Je pense qu'il y a certains critères indispensables pour faire un bon ingénieur R&D, du moins dans une structure comme la mienne :

  • Aimer la technique et le développement. En gros, être passionné pour ce que l'on fait. J'imagine mal un ingénieur dans mon équipe qui n'aimerait pas se coder des trucs chez lui ou s'intéresser, au moins de loin, à l'informatique théorique.

  • Être un minimum pédagogue. Dans ce métier, on passe notre temps à faire le pont entre le chef, les autres ingénieurs, et ce que la boîte ne connaît pas. Ça demande donc d'être capable d'expliquer du mieux possible ce sur quoi l'on travaille, à moins de se voir condamné à réfléchir seul.

  • Lire l'anglais technique couramment. Mais ça, c'est aujourd'hui la base de pratiquement n'importe quel poste en informatique.

  • Avoir le goût du challenge. Ne pas aimer que quelque chose nous résiste, et avoir cette obsession de comprendre comment ça marche, et suffisamment d'imagination pour essayer de le reprendre à son compte.

Un petit mot pour la fin ?

I love deadlines. I love the whooshing noise they make as they go by.

Douglas Adams


  1. Entendre par là : « je faisais tout le temps des bringues mémorables avec mes potes et c'était cool, mais ça grattait très fort aux partiels ». 

  2. Ce qui, entre nous soit dit, n'a pas arrangé mon caractère studieux1 ! 



19 commentaires

Excellente interview encore une fois, bravo à tous les deux.

J'ai exercé le même métier, dans un domaine fonctionnel complètement différent, et il est intéressant de voir à quel point je retrouve des points communs.

Qu'il s'agisse de recherche scientifique ou n'importe quoi d'autre, l'essentiel à retenir de cette interview c'est l'intervention en amont du projet pour se poser les bonnes questions.

J'ajouterai quelques trucs à cette interview :

  • Il faut une certaine faculté d'abstraction : on intervient sur un projet qui n'est pas formalisé, qui n'est pas réalisé, qui en est à la phase "idée" pour lui faire prendre forme. Il faut donc être capable de raisonner de façon abstraite sur des idées et non du code ou des écrans. Il faut parfois se faire violence pour ne pas mettre la charrue avant les boeufs et se dire "OK, ce concept représente ça" c'est vague, c'est flou, mais je le comprends, même si je ne saurais, pour l'instant, pas le modéliser.

  • Il faut être capable de repérer les blocages potentiels. Là où ça va coincer. C'est amusant de voir comment, après quelques années d'expérience, à la simple lecture d'un cahier des charges on repère très rapidement ce qui ne va pas. Ce qui va poser des soucis. Parfois on se plante, évidemment, mais l'expérience aidant, on finit par se surprendre à se dire "oula, ça, ça pue, c'est pas clair ou ça va être indémerdable".

  • De là va découler le bon PoC, le bon proto. Le bon proto c'est pas le truc qui fait tout, c'est le truc sur lequel sans y passer trop de temps on a démontré (proof) qu'on peut éliminer les points bloquants (concept) et que ça peut fonctionner.

  • Ne pasavoir peut de bidouiller, défaire, refaire. Ne pas s'attacher aux détails. Faire la part des choses entre l'essentiel et les bells & whistles. Il faut vraiment savoir bidouiller et aimer ça. Prendre une lib, partir sur une techno inconnue sans aucun a priori, c'est essentiel.

  • être capable de prendre de la hauteur (ça rejoint le point 1). Le client aura la tête dans le fonctionnel de son logiciel, les développeurs dans leur code. Il faut être capable de faire la part des choses entre ces deux modes pour garder la tête froide.

Ce sont des qualités à avoir pour exercer ce métier mais aussi les qualités que ce métier développe. Et c'est extrêmement enrichissant.

Si je devais résumer ce métier en une citation, je dirais :

Voir, dans les frémissements du temps, les orages à venir et les soleils nouveaux.

Imre Lisztöf

Happiness is a warm puppy

+10 -0
Staff

Merci pour cette interview très intéressante !

Edit : ma remarque concerne en fait plus les POC que les prototypes, cf les 2 messages ci-dessous.

Dans la réalité, les prototypes sont souvent repris tels quels et intégrés au système moyennant quelques retouches.

Je ne sais pas comment c'est géré dans le cas où le prototype est pour ta propre entreprise ; mais si tu prototypes pour un client tiers, il a la fâcheuse tendance à vouloir faire comme tu décris. En mode "le prototype est fait donc tout est déjà fini, y'a plus qu'à utiliser le prototype en production"1.

On peut pallier ce problème en concevant des prototypes qui sont volontairement inutilisables en production ; qui ne font que leur boulot de prototype (et éventuellement de socle technique) et pas plus, parce que ce n'est pas son boulot. Et ça rejoint ce que dit Javier.


  1. C'est le cas dans plein de domaines, y compris l'industrie lourde où les investissements se chiffrent en milliards d'euros. Par exemple, les centrales électriques Superphénix et l'EPR de Flamanville sont des prototypes, ce qui est présenté comme d'énormes problèmes sur un modèle de série sont en fait des problèmes (plus ou moins) normaux sur un prototype… 

Édité

Staff

Dans la réalité, les prototypes sont souvent repris tels quels et intégrés au système moyennant quelques retouches.

Je ne sais pas comment c'est géré dans le cas où le prototype est pour ta propre entreprise ; mais si tu prototypes pour un client tiers, il a la fâcheuse tendance à vouloir faire comme tu décris. En mode "le prototype est fait donc tout est déjà fini, y'a plus qu'à utiliser le prototype en production"[^industrie].

SpaceFox

Personnellement (j'ai un poste similaire dans une partie R&D de taille relativement similaire à celle de nohar), j'ai trouvé comme solution de faire une distinction clair entre POC et proto.

  • Quand je fais un POC, c'est juste pour valider que la techno à un interet pour nous, faire sauter les verrous techniques et vérifier que la solution testé est pertinente sous les contraintes de ma boite. Ce code est volontairement inutilisable. C'est souvent un assemblage de petits scripts et de notebook IPython permetant de faire la validation de principe.
  • Si le POC a été concluant, je vais faire un prototype. Là ça doit clairement ressembler à un produit finit pour lever toutes les petites contraintes et chiffrer précisément ce que ça apporte. Cela me ressert souvent de base pour faire des tests d'évolutions.

Le proto validé est alors envoyé a un de mes collegues devant le mettre en production. Si le proto est viable, il ne fait que des modifs de "glues" pour communiquer avec le système réel. Une réécriture complète, dans ma petite structure, est assez rare et est souvent faite presque uniquement pour des raisons de performances (mes proto étant souvent fait en python, tout ou une partie du code peut gagner à un passage en natif, mais ce n'est pas évident).

Dans tous les cas la mise en place d'un proto en production ou en "quasi-prod" (ex: tourne en parralèle d'un autre service déjà existant) est presque indispensable pour détecter certains problèmes de scalabilités et de confrontations à des données réels.

+2 -0

J'aime beaucoup cette distinction entre PoC et proto.

On les utilise souvent comme synonymes mais c'est vrai qu'on sent bien dans le boulot deux notions différentes. Le "truc qui permet de valider une techno" vs "le truc qui ressemble à ce qu'on va faire". Autant utiliser les deux termes pour lever l'ambiguité.

Happiness is a warm puppy

+0 -0
Staff

Hmmm c'est vrai que j'ai écris "proto", mais dans les faits c'est plutôt des POC qu'on nous demande.

SpaceFox

Ça peut dépendre du domaine. Dans mon cas je me débrouille pour que le POC ne soit pas utilisable en prod (car je sais que la tentation sera grande de ne pas le refaire proprement pour gagné du temps). Plus que le code, c'est les sorties qui en fond quelque chose d'inutilisable. Quand je fais un POC, ce que je présente a ma hiérarchie ce sont des stats et des courbes en leur disant "Regardez, cette solution semblerait viable, on peut passer à l'étape suivante". Et comme je sais que l'étape suivante, le proto, risque d'arriver en prod tel quel, je fais l'effort d'une réalisation propre et avec certaines contraintes de prod (ex: pas de lib en GPL qui nous contaminerai).

+0 -0

Super article qui donne un bon aperçu du métier (de l'extérieur) ! Bravo à Nohar et Eskimon !

Médicament flemmard aux pul(p)sions imprécises. “Don’t wait for the perfect moment. Take the moment and make it perfect.”

+0 -0
Staff

Hmm, dans mon vocabulaire (comprendre par là, celui de ma boîte), "POC" a 2 significations, mais dans les deux cas on parle de POC d'un système complet (pas juste une feature).

Ça peut être un "POC R&D", interne, pas du tout codé pour être prod-ready. Disons que ça désigne "une pré-version qui marche à peu près de notre [truc] du futur" et sur lequel on fait toute notre R&D.

Ça peut être un "POC" au sens marketing, i.e. une grosse démo d'un système dans une version à peu près stable + agrémenté de quelques protos, à un client auquel on compte essayer de vendre la "version du futur" (s'il nous l'achète, on pourra la développer). En gros, une démo pour montrer aux grosses huiles chez le client qu'on a le savoir-faire, qu'on est réactifs et que ça marche.

C'est vrai que j'ai pas parlé des POC R&D dans cette interview. Pourtant c'est ce qui a occupé 90% de mon année 2014. :}

Édité

I was a llama before it was cool

+1 -0

Super interview ! Pour moi qui suis en prépa et qui souhaite au départ faire des études d'ingénieur en informatique, ça me permet d'avoir un point de vue "interne" d'un job dans le domaine informatique, et qui semble vachement intéressant (pour peu que l'on aime devoir perpétuellement chercher, et découvrir, de nouvelles choses) !

Peut-être ce témoignage m'ouvrira-t-il de nouveaux horizons ^^ . Quoi qu'il en soit, merci pour ce très bon article !

+0 -0

Article très intéressant.

J'ai souvenir d'avoir lu ton témoignage dans le sujet d'une école sur OC ; étant dans cette même école, il est vrai que le niveau technique n'est pas exceptionnel…

Sinon j'avais quelques questions pour les gens qui font de la R&D en entreprise : est-ce qu'on peut comparer ça à de la recherche telle que peuvent en faire des universitaires (doctorants et docteurs) ou pas du tout ?

J'observe aussi très fortement le clivage manager / expert technique dans les conférences qui nous sont données par les entreprises. N'étant pas du tout intéressé par le management, c'est ce deuxième profil qui m'intéresse le plus. À votre avis, y a-t-il de réelles opportunités en matière d'évolution de carrière dans le domaine ou faut-il nécessairement toucher un peu au management pour évoluer ?

Continuez cette série, c'est vraiment super ! ;)

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” – Rich Cook

+0 -0
Staff

Sinon j'avais quelques questions pour les gens qui font de la R&D en entreprise : est-ce qu'on peut comparer ça à de la recherche telle que peuvent en faire des universitaires (doctorants et docteurs) ou pas du tout ?

Réponse courte : pas du tout. :D

On utilise parfois les mêmes outils (publications, recherche biblio) mais les enjeux sont complètement différents. En R&D on a pour objectif de déterminer si/et comment la boite peut le faire avec ses moyens à elle. En recherche, le but est plutôt de faire avancer la science (un échec est un résultat aussi important qu'un succès).

Édité

I was a llama before it was cool

+2 -0

Pour avoir bossé en R&D (même si le terme est assez flou finalement, j'y reviendrai) et dans la recherche, effectivement cela n'a rien à voir.

R&D reste encore assez vague, certaines startups te diront faire de la R&D par exemple parce qu'elles utilisent une bibliothèque de reconnaissance optique de caractères. Tu admettras qu'on est très loin de la recherche fondamentale. Même de la recherche appliquée.

L'idée qu'englobe R&D, souvent, dans le langage commun (vous noterez les pincettes hein) c'est "chercher des solutions techniques (innovantes) à des problèmes 'nouveaux'". Si on en croit l'article de Wikipedia en fait la recherche fondamentale et la recherche appliquée seraient des sous-composantes de la R&D. Là où en fait, si tu entends quelqu'un te dire qu'il bosse dans le département R&D d'une (petite) entreprise, tu aurais bien du mal à distinguer ça de l'ingénierie classique (comme je l'ai dit : "trouver des solutions techniques à des problèmes fonctionnels".

En gros quand un client (une chaîne de supermarché) dit à ta boîte "on aurait besoin de lire les tickets de caisse automatiquement", la boîte va répondre "on va faire plancher notre équipe R&D dessus", au final, est-ce-que c'est réellement de la R&D ? Difficile de répondre.

J'observe aussi très fortement le clivage manager / expert technique dans les conférences qui nous sont données par les entreprises. N'étant pas du tout intéressé par le management, c'est ce deuxième profil qui m'intéresse le plus. À votre avis, y a-t-il de réelles opportunités en matière d'évolution de carrière dans le domaine ou faut-il nécessairement toucher un peu au management pour évoluer ?

Tu es parti sur une voie (l'informatique, le monde du SI) qui reste presque un des seuls à ne pas trop subir la violence du marché de l'emploi (y'en a d'autres mais tl;dr : "on n'est pas à plaindre").

Le truc à garder à l'esprit tout au long de ta future carrière : c'est toi qui détermine ta carrière. Ca peut paraître stupide et bisounours à entendre, et quelques années en arrière je me serais certainement moqué de moi en m'entendant dire la chose suivante : "Tant que tu aimes ce que tu fais, tu évolueras". Dans ce secteur d'activité, il y a pas mal de demande. Aucune raison donc de ne pas être acteur de sa propre carrière.

Essaie de toucher au management si tu en as envie (les stages peuvent être une bonne opportunité par exemple, j'ai vu en stage que ça ne me plairait pas, par exemple), lances-toi dans la R&D si c'est ça qui t'intéresse, développe si tu te sens bien à écrire du code et le tester, fais du système si ça te chante.

Y'a des perspectives d'évolution partout, des experts techniques sont payés très chers dans certaines boîtes, des managers sont embauchés tous les jours par des SSII. Je dresse volontairement un portrait trop idyllique mais je pense que c'est le meilleur conseil à donner à quelqu'un qui sort d'école : passe tes premières années de travail à trouver ce qui te plaît : c'est le truc le plus important de ta carrière, et ne laisse pas les gens ou "conventions du métier" dicter ta carrière, c'est un discours de recruteur à la con.

Édité

Happiness is a warm puppy

+2 -0
Staff

Concernant la différence avec le monde académique, pour avoir fait une thèse avant, je confirme ce que dit nohar. En fait a de rares exceptions pret, ce que tu fais c'est (quand tu es dans la partie R d'une entreprise) ce qu'on appel du transfert technologique. Le principe est de prendre ce qui peut marcher dans le monde académique et essayer de le faire fonctionner sous les contraintes de ta boite.

En réalité quelques entreprises on des vrais pôles de recherche type académique mais ce serait faut de te dire que c'est courant. Ça concerne que de grosses entreprises Qui ont les moyens et l'intérêt pour le faire. En France ça concerne des boites comme Orange ou Thalès. Criteo, qui pourtant a pas d'intérêt a le faire, viens tout juste de constituer une équipe de recherche fondamentale. Autant te dire que si ça existe, les places sont chers.

Pour me côté expertise Vs Management, comme dit par Javier n a la chance d'être dans un domaine ou c'est possible mais il faut garder a l'esprit que ce n'est pas dans la mentalité des DRH en france (a la difference des pays anglo-saxons ou l'expertise est reconnu et cher payé).

+0 -0

J'observe aussi très fortement le clivage manager / expert technique dans les conférences qui nous sont données par les entreprises. N'étant pas du tout intéressé par le management, c'est ce deuxième profil qui m'intéresse le plus. À votre avis, y a-t-il de réelles opportunités en matière d'évolution de carrière dans le domaine ou faut-il nécessairement toucher un peu au management pour évoluer ?

Ekron

Oui et non. Oui parce qu'on peut vraiment trouver des postes d'expert si on est bon et passionné par quelque chose, et avec une rémunération qui suit. Quand un patron se rend compte qu'un de ses employés a une compétence irremplaçable, généralement ça aide.

Non parce qu'en France il est malheureusement inacceptable pour un chef d'équipe d'être payé moins que les autres, ce qui grossièrement contribue à figer les salaires tant qu'on n'est pas à un poste de management. C'est nul, contre-productif mais c'est dans la culture… J'ai déjà rencontré des gens qui étaient chefs de projet pour le salaire mais que ça n'intéressait pas.

TL;DR : si tu es vraiment bon, ça va.

Helium Rain, un space opera réaliste - Code source disponible !

+0 -0

Merci à tous pour vos réponses. :) Dans le cadre de ma Junior-Entreprise nous avons eu l'occasion de recevoir des SSII comme Extia ou Amaris (et j'ai croisé Alten au congrès national), et elles savent particulièrement bien se vendre… Alors, quand on oppose cela aux ingénieurs seniors qui conseillent de les éviter, il y a de quoi rester un peu perplexe.

J'aimerais bien voir ce qui se fait à l'international, mais la majorité de nos opportunités ce sont ces fameuses SSII qui exportent leurs ingénieurs et leur modèle d'évolution avec.

Édité

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” – Rich Cook

+0 -0

Hmmm, dans le contexte Junior-Entreprise, avec Alten/EY ou BNP, ces partenaires ne cherchent pas forcément le côté technique. Même si dans ce mouvement la part des ingés est supérieure à celles des commerciaux, les offres qu'ils vont proposer seront souvent plus fonctionnelle, orientées management et conseil que technique et développement. T'auras des experts techniques dans ces boîtes bien sûr, mais tu vas pas les retrouver en CNE/CNH, c'est souvent l'équipe RH et du senior qui font le déplacement. La technique c'est pas trop leur truc. Je pense que les opportunités que tu auras avec ces SSII (je bosse actuellement dans une SSII de ce type) sont des bons départs pour se lancer, avec l'opportunité de bosser pour de gros clients. Si tu veux vraiment devenir expert technique je suis pas sûr que ça soit le bon endroit.

EDIT : Hésite pas à me MP si tu veux échanger J.E. et débouchées tout ça

Édité

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte