- Mèkiétu ?
- C’est quoi un firmware engineer, et comment en es-tu arrivé là ?
- Qu’est-ce qui te plaît le plus/moins dans ce travail ?
- Le Top 3 des pires/meilleurs projets ? Le 2 va vous étonner !
- Quel conseil aurais-tu voulu qu’on te donne au début de ta carrière ?
- Si je passais dire bonjour, je trouverais quoi sur ton bureau ?
- Le mot de la fin ?
Mèkiétu ?
Salut salut !
Je suis Eskimon, un « jeune » (plus pour longtemps 
) ingénieur du monde de l’informatique, plus particulièrement de l’informatique embarquée. Je travaille actuellement comme firmware engineer 
dans une entreprise angevine qui est spécialisée dans l’IoT1 B2B : Qowisio.
Je suis accessoirement fan de séries diverses et variées, connues et inconnues, et futur papa rêvant d’un monde meilleur pour ses bouts d’chou.
Enfin, j’adore partager ce que je connais ! C’est notamment pourquoi j’ai coécrit un tuto sur Arduino ainsi que divers articles, tutoriels, MOOC, blog. </pub> 
Ah, et sinon, je vais essayer d’être original, mais mon travail recoupe beaucoup de choses qui ont pu être dites dans des interviews précédentes comme celle de Natalya ou zeqL, par exemple. 
-
Oui, je connais déjà @internetofshit ;) ↩
C’est quoi un firmware engineer, et comment en es-tu arrivé là ?
Le firmware engineer c’est le joli mot pour dire que je fais du logiciel qui va fonctionner tout seul dans son coin dans un matériel bien précis. Plus particulièrement, pour mon travail, je suis développeur de logiciels embarqués dans des objets que l’on connecte ensuite à un réseau via ondes radios.
De manière simple, les objets que nous développons s’articulent souvent autour d’un ou plusieurs capteurs qu’il faut interfacer avec le microcontrôleur/microprocesseur qui se chargera ensuite d’envoyer les données à une puce radio (qui peut être intégrée directement dans le microprocesseur). Cette dernière transforme alors le message en ondes radio qui seront captées par notre réseau d’antennes.
Pour en arriver à tout cela, pas mal de compétences entrent en jeu, donc il est nécessaire d’avoir plusieurs cordes à son arc. En effet, entre l’électronique pour interfacer les capteurs et la programmation des microcontrôleurs, il faut être assez souple. Du coup, j’ai suivi une formation alambiquée.
En effet, sorti du bac je ne savais pas quoi faire. Ma prof de physique-chimie de l’époque m’a alors donné le meilleur conseil de mes études post-bac : va visiter l’IUT. Et là, ce fut la révélation. J’ai rejoint l’IUT GEII d’Angers pendant deux supers années. J’y ai notamment découvert la robotique au sein du club robot associatif local, et me suis éclaté à participer à des compétitions de robotique comme Eurobot (que du bonheur !). C’est d’ailleurs ça qui a déclenché mon goût pour les systèmes embarqués.
Une fois sorti de l’IUT, je suis parti un an en Angleterre pour y faire un Bachelor of Science in… Robotics. Ça a surtout été l’occasion de découvrir un mode de fonctionnement vraiment différent, de me faire plein de copains de par le monde, et bien sûr, d’approfondir ma connaissance de l’anglais !
Une fois de retour en France, j’ai rejoint une petite école d’ingé (l’ISTIA à Angers) pour y faire un diplôme en automatique et génie informatique. La recherche étant un aspect m’intéressant beaucoup, j’y ai aussi fait un double diplôme de master de recherche à propos des systèmes dynamiques (une discipline présente dans la robotique). Une fois cela fait, ce fut le début de ma grande aventure de professionnel… 
Qu’est-ce qui te plaît le plus/moins dans ce travail ?
J’aime beaucoup la pluralité des tâches que j’effectue au quotidien. Ceci est dû, d’une part à ma fonction, mais d’autre part aussi au fait que je sois dans une petite entreprise, ce qui a tendance à encourager ce genre de fonctionnement.
Par exemple, bien que je passe la majeure partie de mon temps à développer des logiciels en C, il m’arrive régulièrement de toucher à d’autres langages comme le Python pour me faire mes propres outils et gagner du temps, voire du JavaScript pour coder des bouts de page Web pour me faire des interfaces sexy pour afficher les données remontées par les objets que je développe.
Il y a aussi une grande part de communication interne et externe. Mon métier est au croisement de deux domaines : l’électronique, qui va développer les cartes sur lesquelles je travaille, et les développeurs infra/Web/app, qui font les interfaces de restitution de données. J’ai besoin des premiers pour savoir comment bien interagir avec les différents composants (voire de prendre moi-même le fer à souder en quelques rares occasions), et il faut aussi que j’interagisse avec les derniers pour qu’ils sachent comment se présentent les données que j’envoie, afin de bien les décoder.
Enfin, bien que nous ayons une équipe « support/hotline », je récupère fréquemment des demandes d’aide de clients, notamment pour la mise en œuvre et l’utilisation de kits de démonstration de notre technologie que nous offrons lors de journées d’initiation à l’IoT (ce qui fait de moi un formateur une fois par mois 
).
Bref, c’est un travail complet sur bien des aspects et j’adore ça, ça rompt la monotonie d’un quotidien clavier/écran !
En revanche, ça veut aussi dire qu’on ne fait pas toujours ce que l’on veut. Il m’est arrivé de devoir travailler sur des technologies très old school (cœur 8051 pour ceux qui connaissent, flashable une seule fois, tous les outils en mode « IDE des années 2000 » sous Windows 
). Quand on a des habitudes sur d’autres plate-formes un peu plus modernes (AVR) voire très modernes (Cortex <3 ), ça pique un peu, et c’est assez pénible de ne pas avoir la souplesse que l’on veut parce qu’un fabricant a décidé de garder ces outils « tels quels et ça ira ».
Le Top 3 des pires/meilleurs projets ? Le 2 va vous étonner !
Les pires
Le top pire fut un de mes emplois. Une société de services m’avait débauché en me proposant un super projet qui correspondait exactement à mon mémoire de master de recherche. J’ai donc changé de travail (pas une grande perte) pour finalement me retrouver à faire un truc pas très palpitant, ne correspondant pas à ce qu’on m’avait proposé, loin de chez moi, et avec des promesses de relocalisation plus proches qui ne se réaliseraient pas. Bref, j’ai claqué la porte au bout de deux mois.
Le second pire ne fut pas si pire (mais sinon ça fait pas un top, alors je cherche !). J’ai travaillé pendant un an et demi en Pologne1 dans une très grosse SSII finlandaise sur les smartphones d’un grand fabricant asiatique (Kamoulox !). Le travail en lui-même aurait pu être très intéressant… s’il n’avait pas été si dur ! Je devais corriger des bugs dans la partie multimédia de l’OS Android (partie multimédia elle-même modifiée par le fabricant). Eh bah croyez-moi, c’est vraiment chaud. Rien que reproduire les bugs pouvait être compliqué. Heureusement, il y avait une bonne équipe ce qui m’a aidé à rester plus longtemps…
Les meilleurs
Sans aucun doute, les meilleurs projets ne sont pas dans la vie professionnelle… J’ai la chance de faire un travail sympa, j’apprends des choses toutes les semaines et les problématiques sont intéressantes. On est une petite structure ce qui donne des projets et de la gestion de projets assez dynamiques. Mais durant ma courte vie de technicien, je pense que mon Top 3 se trouve en dehors de cela…
Neumber Ouane : Zeste de Savoir ! J’ai participé pendant de nombreux mois à ZdS en tant que dev et j’y ai appris tellement de choses ! Les gens sont sympas, le projet aussi, et techniquement à la hauteur de beaucoup de réalisations de calibre professionnel (et même au-delà en termes de qualité de gestion du code et de la plate-forme). Bref, top.
Neumber Tou : mes années club robot. Ça a formé le développeur que je suis. Ce furent mes premiers vrais projets d’équipe et l’ambiance lors de compétitions est tellement forte que ça marque !
Neumber Throui : le projet Toba. C’était un projet universitaire de réalisation d’une maquette de voilier autonome. J’y ai notamment découvert Arduino. Le périmètre du projet était tellement sympa, allant de la réalisation d’un simulateur du comportement du bateau via la modélisation de son modèle physique et de sa loi de commande, jusqu’à l’intégration de l’électronique/informatique dans la maquette avec tests hilarants sur un lac local, et réalisé avec deux grands copains, que ce fut un grand moment de mes études.
-
Dzień dobry! On m’a demandé de parler de la Pologne. Je n’aurai qu’une chose à dire : vous ne pouvez pas prétendre apprécier (ou pas) la vodka avant d’avoir goûté la vodka polonaise. C’est tout. ;) ↩
Quel conseil aurais-tu voulu qu’on te donne au début de ta carrière ?
Avant même ma carrière, c’est pendant mes études qu’un conseil m’aurait été utile : ne fais pas d’impasse.
Pendant mes études, j’avais tendance à être tech only, et à ne pas faire très attention aux matières complémentaires comme la compta ou le droit, par exemple. Finalement, je l’ai regretté un peu en début de parcours, car avoir des connaissances de ce genre, c’est toujours utile dans le monde pro (pour éviter de se faire entourlouper par une SSII, par exemple).
En plus, finalement, ça s’avère assez intéressant comme sujets. J’en ferais clairement pas mon métier, mais quand même, c’est toujours sympa de voir d’autres choses, et ça finit toujours par servir.
Si je passais dire bonjour, je trouverais quoi sur ton bureau ?
Pas mal de bordel, selon que vous passiez juste avant que l’envie de ranger me prenne ou pas.
En règle générale, il y a des cartes électroniques prototypes faites par l’équipe hardware (ils font les cartes, les soudent, puis me les font suivre pour que je les programme) et plusieurs outils de mesure, selon ce sur quoi je travaille. On a :
- une alimentation stabilisée et un multimètre de labo. Soit pour juste tester les cartes, soit pour étudier la consommation de l’ensemble (vu que les produits sont sur batteries la majeure partie du temps, il faut traquer tous les µA pour avoir la meilleure autonomie possible) ;
- de temps en temps, un oscilloscope plus ou moins compliqué pour analyser les trames de protocoles (SPI, I2C et autres joyeusetés) pour mettre en œuvre certains composants ;
- à l’occasion, un analyseur de spectre, pour regarder si mes paquets radios sont bien où je veux comme je veux ;
- un Raspberry Pi bricolé pour analyser la radio (comme ci-dessus, mais en version « haut niveau », pour vérifier si le contenu des messages radios est correct) ;
- un cahier pour griffonner ;
- des post-it (j’adoooooore les post-it) ;
- une tasse à café, évidemment.
Le mot de la fin ?
Si vous avez l’occasion de partir étudier à l’étranger, faites-le ! Vous en ressortirez grandi et la langue anglaise est indispensable dans ce corps de métier.
Si vous voulez travailler dans l’informatique, apprenez à utiliser git ! Tout le monde l’utilise, peu de gens le connaissent vraiment. C’est dommage.
Et sinon, soyez curieux et prenez le temps d’y penser ! C’est vraiment à mon sens le conseil en or et une qualité qui fait la différence entre le bon ingénieur et un bon ingénieur (les vrais savent). N’hésitez pas à poser des questions et à vous intéresser à tout !
Un petit coucou à elyppire pour la prise en charge de l'article et, comme d'habitude, merci à Dominus Carnufex pour sa relecture et son saignement d’œil sur les fautes.
