INRIA
Nous voici donc au moment de mon premier job officiel en tant qu’ingénieur en informatique. Je suis donc intégré à une équipe de recherche au sein d’INRIA Grenoble. Les choses sérieuses commencent pour moi.
Je suis donc embauché, en CDD sur un projet de recherche de trois ans. Il s’agit du projet AppsGate. C’est un projet de recherche sur l’habitat intelligent. L’objectif est de proposer un moyen simple et fiable pour offrir à tous, le moyen de programmer sa maison et tous les objets connectés qui s’y trouve.
C’est un projet conséquent, impliquant trois équipes de recherche sur Grenoble et des partenaires industriels dans toute l’Europe.
L’équipe PRIMA
Pour ma part, j’ai été intégré à l’équipe PRIMA à INRIA Grenoble. C’est une équipe qui, à l’époque, travaillait sur la robotique, la voiture intelligente et les interactions entre humain et dispositifs physiques.
L’objectif de PRIMA, dans le cadre d’AppsGate, était de s’appuyer sur des résultats de recherches d’une équipe grenobloise sur la résilience des systèmes distribués pour construire un système de domotique domestique. Ce système avait pour but de s’intégrer dans une box TV pour pouvoir être distribué au plus grand nombre. Les contraintes étaient donc un hadware très réduit avec un petit processeur, peu de RAM et peu de persistances. Pour vous donner un ordre d’idée, le Raspberry PI, premier du nom, était une de nos plateformes de dev, plus rapide pour avoir un feedback lors des tests et des phases de debug que la plateforme cible. Je vous mets un lien vers les specs si vous voulez voir à quoi ça ressemble
Le projet
À Grenoble, nous avions deux objectifs pour ce projet. Le premier était de concevoir la partie logicielle qui permet d’agréger les différentes technologies de capteurs (Enocean, Watteco, Bluetooth Low power, etc.). Le deuxième était de mettre en place une application PC et tablette pour permettre de programmer son habitat. Les enjeux étaient :
- Avoir un système qui tourne avec peu de ressource
- Avoir un système résilient, il doit pouvoir récupérer d’une panne sans intervention et s’adapter aux défaillances des capteurs
- Avoir une interface facile à utiliser pour n’importe qui permettant de gérer les objets connecté et de programmer sa maison
Me concernant, je devais intégrer les différentes technologies de capteur dans notre système. Ceci se faisait en partenariat avec différentes entreprises partenaires du projet. Je devais également implémenter la logique de résilience autour des capteurs et permettre de créer des capteurs virtuels.
Franchement, le projet était ouf, il y avait des moyens ce qui a permis d’avoir une bonne équipe pour travailler dessus et tous les équipements dont nous avions besoin pour tester en condition réelle et faire des expérimentations.
Je me souviens que nous avions participer au salon Experimenta à Grenoble. Dans ce dernier, nous avions réalisé un faux appartement pour présenter l’avancement de notre projet. Les gens qui visitaient le salon pouvaient programmer l’appartement avec un iPad. Ils avaient les informations de consommation des différentes prises, pouvaient contrôler la lumière, l’aspirateur, la machine à café, la musique et la télévision. Le plus intéressant était de programmer des scénarios. Par exemple, quand j’entre dans le salon, la lumière s’allumer et la maison joue une musique d’ambiance. Tout s’éteint lorsque je sors. Et ça fonctionnait du tonnerre. Les gens ont adoré et on était fier de notre travail.
Aujourd’hui ça parait peut-être mainstream ce que je vous raconte, car il y a beaucoup de systèmes qui proposent cela. Mais à l’époque, c’était carrément de l’innovation. Surtout l’aspect programmation par l’habitant.
Mon taf
Comment s’est passé mon boulot dans le projet ? Franchement, c’était une super expérience. J’ai appris des trucs dingues sur les réseaux de capteurs et la résilience d’un système. J’ai pu faire des démos à des utilisateurs finaux et pour des événements sur l’innovation. Niveau code, en vrai, c’était un peu compliqué. Je sortais d’école et les bonnes pratiques, je ne savais pas du tout ce que c’était. Et il n’y avait pas de développeur senior sur le projet. Même si les chercheurs étaient très bons en algo et sur les principes théoriques, côté industrialisation, c’était moins évident.
J’ai donc fait toutes les conneries possibles et imaginables. La galère de coder sans tests, je ne parle même pas de faire du TDD. On avait aucun test automatisé. J’ai codé tout seul dans mon coin, en me jetant direct dans le code. Bref, tout ce qu’il ne faut pas faire pour mener un projet à bien.
Heureusement, dans ce projet, je n’étais pas le seul jeune diplômé embauché. Et avec le dev qui devait coder l’interface de programmation de la maison, on a fini par trouver un moyen de bosser ultra efficace.
Premièrement, on reprenait toutes les tâches qu’on devait réaliser sur un tableau blanc. On repartait du métier et si nécessaire, on remettait en cause les décisions prises en amont. En gros, on ne codait que ce avec quoi on était d’accord et qu’on était sûr d’avoir compris.
Ensuite, on modélisait le métier. Toujours en étant au tableau, on faisait apparaître les concepts à manipuler et les liens entre ces concepts. Ensuite, on regardait comment ces concepts étaient utilisés dans le back et dans le front. Cela nous permettait de tirer les projections techniques des deux côtés et de virer ce qui n’avait pas d’utilité pour le moment.
Enfin, on contractualisait les interactions front et back. Nous avions une communication via une API et nous nous mettions d’accord sur les endpoints et l’ensemble des informations échangées.
Toutes ces étapes étaient réalisées sur un tableau blanc. Aucune ligne de code, pas même un ordinateur. Nous étions dans le même bureau et les résultats (modélisation métier et contrat d’API) restaient affichés le temps que nous terminions l’implémentation. Cela constituait pour nous une itération du produit. Le front et le back étaient réalisés en parallèle. Grace à notre contrat, nous avons pu mettre en place de stub pour valider notre avancement indépendamment l’un de l’autre.
C’est aussi à ce moment-là qui nous avons commencé à intégrer des tests automatisés pour nous assurer du bon fonctionnement de nos scénarios.
C’était un fonctionnement idéal. Cela a tenu jusqu’au départ de mon collègue qui ne supportait plus les dérives du projet et le management. Je n’ai pas réussi à mettre en place de fonctionnement identique par la suite avec les nouvelles recrues.
Ce qui m’a plu
J’ai adoré dans ce projet bosser avec OSGi. C’est un framework Java qui permet de réaliser une architecture à composant dans un soft monolithique. En gros, votre logiciel est par essence découpée en service. On peut voir ça comme du micro-service, mais dans une seule unité déployable. Par rapport à un programme classique, cela force à avoir un programme où tous les éléments sont découplés. Les dépendances ne peuvent pas se faire qu’au moyen d’une interface et non d’une implémentation.
Quand on y regarde de plus près, aujourd’hui, c’est devenu un classique avec l’architecture hexagonale. Mais ici, le framework oblige à le faire de cette manière, contrairement à l’architecture hexagonale qui doit être une pratique de l’équipe de dev.
En vrai, c’était super de voir dans son programme tous les composants de la maison instanciée et se connecter dynamiquement au besoin. De voir que lorsqu’une composant plante, le système est capable de remplacer la dépendance avec une autre instance qui peut rendre le même service. Et chercher à redémarrer l’instance qui est tombée pour remettre le système d’aplomb. Si vous pensez à Kubernetes en lisant ça, c’est très clairement la même chose, mais à l’échelle d’un programme seulement.
J’ai adoré collaborer avec plein de boites qui travaillent du côté hardware. C’est dingue les contraintes qu’on peut avoir et qui compliquent beaucoup la façon dont on doit développer.
J’ai aussi aimé bosser dans une équipe assez nombreuse. À Grenoble, nous étions 7 à temps plein sur le projet et plusieurs dizaines en comptant toutes les équipes. Ce fut une expérience intéressante dans une contexte internationale.
Ce que j’ai moins apprécié
J’ai travaillé dans le cadre d’un projet de recherche avec des laboratoires publics. Je dirais que l’ambiance là-bas, c’est quitte ou double. Il y a des chercheurs ultra-compétents et bienveillants et d’autres non. Malheureusement, ces derniers sont sur-représentés. C’est un milieu très politisé et il y a des choses pas claires dans la gestion des projets et des équipes. Il y a énormément de pistons et de retour d’ascenseur qui donne lieu à des décisions qui n’ont aucun sens pour l’équipe ou le projet sur lequel on travaille. Ça peut vite devenir démoralisant.
Il y a aussi certains universitaires qui ont du mal avec les ingénieurs. Je ne sais pas si c’est parce qu’ils sont en manque de reconnaissance. Mais le nombre de fois où l’on (les ingénieurs de l’équipe) s’est pris des réflexions qui nous faisait comprendre qu’on était inférieur parce qu’on était juste ingénieur.
Ça casse assez vite l’ambiance quand les membres de ton équipe te considère comme inférieur. Ce n’est pas évident de trouver sa place dans ces conditions.
Le dernier point qui me dérange, c’est que dans la recherche, le but, c’est la recherche. Sous-entendu l’objectif pour les laboratoires était de pouvoir publier des articles et d’être publié dans des conférences. Si bien, qu’au final, les projets n’aboutissent à rien. Même en ayant des résultats intéressants, il n’est pas prévu de faire un produit. Ce n’est pas du tout l’objectif. À moins qu’un des chercheurs soit motivé pour lancer une startup.
Conclusion
C’est une expérience qui en vaut la peine, tant pour les bons que les mauvais côtés. Je ne suis pas allé au bout de mon CDD. Arrivé sur un début de la dernière année, le projet s’est concentré sur les aspects publications et plus grand-chose du côté du « produit ». Je commençais à m’ennuyer ferme à me contenter de maintenir la plateforme pour les différentes expériences. Je savais également qu’il n’y avait pas de suite.
J’ai donc démissionné 6 mois avant la fin de mon contrat. J’ai suivi un membre de l’équipe PRIMA qui avait rejoint une plateforme d’innovation qui venait de se monter sur Grenoble.
