Le meilleur job que j’aie jamais eu

Temps de lecture estimé : 6 mn

La carte de la semaine me propose d’écrire sur le meilleur job que j’aie jamais eu ! Mais bon, pour l’instant j’ai une expérience professionnelle assez faible, donc je vais plutôt parler d’un des projets d’école d’ingé qui m’a beaucoup plu !

Un peu de contexte : les projets dans mon école d’ingénieur

J’ai fait des études d’ingénieur en acoustique et vibrations. En parallèle des cours, nous avions des projets à réaliser en groupe qui nous permettaient d’appliquer ce qu’on avait vu en théorie.

Les projets étaient de deux types : recherche ou industriel. Les projets recherche étaient des projets proposés par les profs de l’école et permettaient notamment de travailler sur un aspect spécifique des thèses que ces profs encadraient. Les projets industriels étaient proposés par des partenaires industriels de l’école, notamment via le réseau des anciens élèves.

Les projets proposés sont majoritairement des projets recherche, mais chaque année il y a des projets industriels, que l’école nous incite à choisir en priorité pour éviter qu’elle démarche une entreprise pour rien.

Le projet que j’avais cette année-là

Un des anciens élèves de l’école, en poste dans l’industrie depuis quelques années, a proposé un sujet sur la perception acoustique. Comme son nom l’indique, il s’agit d’étudier le lien entre des phénomènes acoustiques (qu’on peut mesurer objectivement) et les réactions des personnes (qui sont moins tangibles).

L’entreprise en question conçoit et produit des chariots télescopiques. Personnellement, je trouve ça fou de se dire que même dans ce domaine, on s’intéresse à des notions de perception acoustique. Et pourtant, c’est très important ! Au-delà des aspects de confort et de santé, ça permet à l’entreprise d’avoir un avantage concurrentiel non-négligeable !

Je ne vais pas rentrer dans les détails du projet, mais il s’est décomposé en 4 grandes parties :

  • une étape de bibliographie où on devait se familiariser avec la perception acoustique, notamment les types d’indicateurs perceptifs utilisés pour caractériser les signaux acoustiques,
  • une étape de mesures acoustiques sur site, où l’on venait mesurer différentes grandeurs acoustiques et vibratoires et calculer les indicateurs perceptifs associés,
  • une étape d’analyse des résultats à travers un plan d’expériences qui permettait de trouver des liens entre les paramètres des mesures (le type de moteur, son régime, etc) et les indicateurs perceptifs calculés,
  • et une étape de test perceptif où des personnes écoutaient les signaux et les évaluaient par comparaison.

Parmi les principales conclusions, nous avions mis en évidence des liens entre la configuration du moteur et les indicateurs observés, et nous avons également confirmé la notion de « signature acoustique » des moteurs (les moteurs produits par différents fabricants étaient perçus différemment).

Pourquoi est-ce qu’il m’a plu ?

Comme dirait Paul Taylor, c’était « for three reasons » !

Tout d’abord, tout le monde avait intérêt à ce que ça marche. Du côté de l’entreprise, le projet était pour eux un moyen de défricher un sujet nouveau (la perception acoustique) sans mobiliser trop de ressources. Ensuite, du côté de l’école, c’était une piste pour un partenariat futur (spoiler : l’entreprise a pris un alternant l’année suivante). Enfin, pour nous, c’était une manière d’avoir une expérience quasi-industrielle durant nos études. Je pense que ces aspects combinés ont fait que chacun a été motivé par le fait de faire aboutir le projet.

Ensuite, l’équipe était super. Nous étions 5, on s’appréciait bien avant le projet mais il nous a vraiment rapproché. De plus, chacun avait ses préférences sur un des aspects du projet. Certains étaient plutôt sur la bibliographie et les mesures, certains étaient plutôt sur le traitement des données et l’organisation des tests, mais personne ne s’est jamais vraiment marché dessus. C’était un juste équilibre.

Et enfin, il m’a plu parce qu’il m’a permis de me découvrir un intérêt pour la programmation. En effet, lorsqu’il a fallu coder un logiciel pour tracer les signaux mesurées et afficher les indicateurs correspondants, je m’y suis attaqué sans broncher alors que jusqu’à présent, je n’étais pas un grand fan de la programmation ! Finalement, j’étais souvent le premier à arriver dans notre salle de projet pour préparer mon ordinateur, et je me suis aussi retrouvé en position de leader naturel auprès d’un ami à qui j’expliquais comment coder telle ou telle fonction du logiciel.

Les conclusions que j’en ai tirées

La première conclusion fut de voir que dans un projet, l’équipe est souvent plus déterminante dans le succès du projet que le sujet lui-même. C’est quelque chose que je n’ai pas remarqué tout de suite, mais que j’ai compris l’année suivante quand je me suis retrouvé dans un projet tout aussi intéressant, mais avec un binôme avec qui je n’ai pas réussi à trouver mon rythme, et avec des encadrants moins présents, notamment car il n’y avait plus d’attentes industrielles cette fois-là. C’est ce qui m’a permis de comprendre les raisons du succès du projet sur la perception acoustique.

Je me suis aussi trouvé un intérêt réel pour la programmation. Dans les projets et les jobs qui ont suivi, j’ai toujours trouvé un moyen d’en faire un peu. Et la plupart de mes ami.e.s vient souvent me demander des conseils lorsqu’ils ont des questions sur ces sujets. Ça ne veut pas forcément dire que je suis bon. Par exemple, j’ai découvert récemment que les scripts que j’avais faits pour ce projet étaient codés avec des techniques peu orthodoxes ! Mais c’est une découverte qui m’a stimulé car j’étais content d’en apprendre plus !

Les liens avec ma situation actuelle

Et enfin, je peux faire beaucoup de liens entre ce projet et ma situation professionnelle actuelle. En effet, actuellement je suis plutôt seul sur mon projet, et les relations avec mes encadrants ne sont pas toujours très simples. Et je pense qu’en plus des problèmes techniques que je rencontre, une partie de l’échec est à attribuer au manque de liens entre les gens.

Et enfin, je remarque aussi que depuis ma sortie d’école d’ingénieur, je poursuis une voie dans laquelle je ne suis finalement pas très bon. Par contre, à chaque fois que je me retrouve à faire de la programmation, c’est rarement une corvée pour moi. Et je me dis que dans le futur, je pourrais trouver un job dans lequel ces aspects de programmation ne sont plus des « side projects » mais le cœur de mon activité. Et là je pense qu’on touche à un léger syndrome de l’imposteur, puisqu’en tant qu’ingénieur acoustique et vibrations, je ne me sens pas encore très légitime pour ça. Mais c’est un autre sujet !

Conclusion

Un peu comme la semaine dernière, c’était un article très agréable à écrire ! J’ai pris plaisir à retourner voir la fiche d’annonce du projet, notre rapport et le poster du projet que nous avions fait ! Évidemment, avec le recul, je vois bien les erreurs que nous avions faites (la manière dont le rapport a été écrit par exemple, ou les erreurs de programmation dont je parle plus haut), mais je mets ça en perspective avec le fait que c’était un projet étudiant et donc qu’il faut le prendre comme tel !

C’est tout pour cette semaine ! À la semaine prochaine !

Laisser un commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *