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. 
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
. Quoi qu'il en soit, merci pour ce très bon article !
