Je vais essayer de répondre pour l’embarqué: le boulot que tu cherches existe, mais il est assez rare. En général on essaye d’éviter les tests terrains parce qu’ils sont coûteux en temps, en logistique, et qu’en général on est moins bien équipés sur le terrain que dans le labo.
De fait, toutes les grosses industries avec du volume, comme l’aviation ou l’automobile, ou celles travaillant avec du matériel cher, comme l’aérospatiale, vont travailler sur des simulateurs.
Il existe néanmoins de nombreux domaines d’application où les tests terrain vont être une part importante du boulot, la robotique, les drones, l’agriculture en sont des exemples. Ce sont des domaines où on n’a pas de simulateur qui remplace parfaitement le modèle réel. Pour autant, même dans ces domaines, tout le monde ne va pas sur le terrain.
Prenons les gens qui bossent sur la partie embarquée d’un drone:
- Les personnes qui font le support bas niveau (boot, installation, update, interfaçage du matériel spécifique de ce drone) ont plus besoin d’un oscillo que d’un drone qui vole: ils vont être entre leur bureau et le labo électronique (on a rarement un analyseur de bus rapides sur chaque bureau).
- Les personnes qui font le soft plus générique (communication avec le sol, gestion des flux caméra, des fichiers de config, enregistrement sur carte SD, mode de pilotage autonome) vont faire le gros de leur travail sur simulateur. J’ai un collègue qui faisait ça, qui sortait un quart d’heure par semaine pour vérifier que le soft continuait à marcher sur un drone réel (donc il flashait un drone, il sortait dans la cour, il l’allumait, captait le GPS, vérifiait qu’il avait un flux vidéo, décollait, faisait un rond dans la cour, atterrissait). C’est pas vraiment le terrain. Cela dit, quand l’activité drone était plus petite, il n’y avait pas de simulateur, et tous les tests se faisaient sur le terrain.
- Les personnes qui travaillent sur des nouveaux capteurs (camera, IMU) le font en condition contrôlées, donc en labo, avec pot vibrant, mires, …
- Les personnes qui travaillent sur le groupe propulsif vont beaucoup travailler sur banc de test. Ça permet d’avoir des mesures de couple, de vitesse, de traction, de courant et de tension. En plus, ça permet d’avoir un système bien immobilisé qui ne blesse personne quand une hélice éclate pendant les tests. Ils vont sur le terrain surtout quand ils passent leur travail à l’équipe suivante.
L’équipe suivante, ce sont les automaticiens (même si le contrôle moteur est aussi de l’automatique). Ils ne sont pas nécessairement des développeurs logiciel, mais les plus petites structures (comme toutes les petites entreprises qui font des robots spécialisés de nos jours) recherchent souvent des automaticiens capable d’implémenter leurs algos sous une forme embarquable. Les algos de contrôle de vol, tout comme, dans d’autres entreprises, des algorithmes de marche, d’évitement, de SLAM (simultaneous localization and mapping) en général vont demander du test grandeur nature pour vérifier qu’ils sont robustes aux irrégularités du monde réel. Mais on dépasse ici les seules compétence de développement logiciel.
Enfin, plus la structure (l’entreprise) est petite, moins les gens vont être spécialisés, et moins ils vont pouvoir s’appuyer sur des outils de développement comme des simulateurs. Ça demande donc des compétences plus générales, plus d’autonomie, pas mal de pragmatisme (pour préférer une solution fiable, simple, rapide à la solution optimale), et ça demande de s’occuper de trucs qu’on trouve chiants mais que personne n’est dédié à gérer.
Bref je pense que tu peux effectivement trouver ton bonheur en embarqué, en choisissant bien tes projets. Par contre ça va demander de creuser les domaines connexes comme l’électronique et l’automatique (à voir en fonction des produits développés).
Mais ça reste une activité annexe par rapport à ce que je suis censé faire : coder.
