Travailler dans l'informatique sans toujours être devant l'écran ?

a marqué ce sujet comme résolu.
Auteur du sujet

Bonjour,

Ayant fait des études d’informatique, j’aimerais dans un premier temps travailler dans ce domaine que j’apprécie. Seulement, après un peu moins d’un an d’expérience en entreprise, je me rends compte que rester devant l’écran toute la journée ne me convient pas. Je me demandais donc si certains d’entre vous ressentaient la même chose et, le cas échéant, si vous étiez parvenus à remédier à ce problème.

J’aimerais beaucoup interagir avec l’environnement, par exemple par le biais de l’agriculture. Mais je ne parviens pas encore à bien définir quelle forme ça pourrait prendre. Notamment, je me demande si développeur embarqué (grosso modo, travailler avec Arduino) permet réellement d’interagir avec le système commandé.

Une autre possibilité que j’envisage serait de travailler comme data scientist appliqué à l’environnement et de profiter de la collecte de données pour prendre l’air.

Merci pour vos retours.

+0 -0

Notamment, je me demande si développeur embarqué (grosso modo, travailler avec Arduino) permet réellement d’interagir avec le système commandé.

Rarement. Tout dépend de l’engin.

Ayant bossé dans l’industrie et l’aéronautique, les objets où s’intègrent mes développements étaient bien trop grands pour que tu y aies accès régulièrement. En général tu bosses dans ce cas avec un périphérique qui simule les entrées / sorties. Tu ne vois le résultat final que lors de la livraison ou lors d’un test intermédiaire.

Une autre possibilité que j’envisage serait de travailler comme data scientist appliqué à l’environnement et de profiter de la collecte de données pour prendre l’air.

De souvenir ce genre de stations sont gérés à distance et je ne crois pas que ce soit le job de l’analyste de faire le relevé sur le terrain…

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+5 -0

Compliqué de nos jours avec la démocratisation des accès à distance.

Pour mon cas, je me suffis avec les installations physiques en datacenter et autres. On est momentanément hors des écrans, mais ce n’est pas non plus la verdure des champs, loin de la (mais ça permet de ne pas être assis sur une chaise devant un écran H24).

Pour éviter les écrans, je pense surtout aux métiers types "prestation chez les clients" où tu navigues du client en client (mais ça apporte tout un lot de contrainte et ce n’est toujours pas la verdure).

Pour ce qui se rapproche le plus de ce que tu envisages, j’essaierai de me tourner vers des projets type start-up mais c’est au cas pas cas encore une fois.

Édité par Nicox11

Mon blog de réseau et informatique https://blog.network-berry.net

+2 -0

Ola,

Les métiers de l’informatique ne se résument pas au dev ou à l’administration système.

il y a les métiers intermédiaires (chef de projet, Architecte de solution avant vente, responsable délivery…) où un background technique sera un atout indéniable.

Par contre si c’est l’écran qui te dérange, la plupart des métiers de nos jours se passent derrière lui.

Pour allier, comme tu le présentes l’agriculture à l’informatique… Pourquoi ne pas envisager des solutions autour de l’embarquée ?

  • Gestion de l’eau selon relevé barométrique
  • Gestion du sol via sonde
  • Automatisation et industrialisation
  • (…)

Ces termes là devraient être accessible au monde de l’agriculture.

Courage :)

+0 -0

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).

+4 -0

Sans vouloir bercer dans le commentaire type "vieux con élitiste" et ne connaissant pas non plus ton background d’informaticien, je tiens juste à préciser que le dev' embarqué ça ne s’improvise pas sur un coup de tête (tout comme on devient pas non plus dev web ou admin réseau du jour au lendemain). Il te faudra connaitre ou apprendre des choses en électroniques ainsi que quelques aspects propre au matériel embarqué.

Perso mon dernier poste était dans une petite structure qui fait dans les objets connecté B2B. Du coup j’ai eu la chance de pouvoir faire pas mal de test "vérité terrain" pour vérifier nos données théoriques face à la dure loi du monde réel. Et effectivement ça permet de prendre l’air :D Mais ça reste une activité annexe par rapport à ce que je suis censé faire : coder.

Édité par Eskimon

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+2 -0

Sans vouloir bercer dans le commentaire type "vieux con élitiste" et ne connaissant pas non plus ton background d’informaticien, je tiens juste à préciser que le dev' embarqué ça ne s’improvise pas sur un coup de tête)…

Je pense que cela s’adressait à moi étant le seul à avoir mentionné l’embarqué :ange:

Plus synthétiquement, tout est possible du moment où l’on se donne les moyens :)

Les connaissances peuvent toujours s’acquérir… Je dirai que pour évoluer, ce n’est pas tant les connaissances techniques mais le savoir être qui est important.

J’ai personnellement choisi une carrière informatique à mes 25 ans… cela fait 23 ans…

Une chose est sur, je ne veux plus faire de "technique" dans ma vie professionnelle ! Mais je suis toujours derrière un écran.

(parceque peut-être, je suis encore un plus vieux con élitiste) :lol: :lol: :lol:

+0 -0

Je pense que cela s’adressait à moi étant le seul à avoir mentionné l’embarqué :ange:

Non, l’OP mentionnait cette possibilité.

Plus synthétiquement, tout est possible du moment où l’on se donne les moyens :) Les connaissances peuvent toujours s’acquérir… Je dirai que pour évoluer, ce n’est pas tant les connaissances techniques mais le savoir être qui est important.

Je pense que notre Eskimon préféré en est parfaitement conscient. ;)

Mais disons que pour beaucoup de gens, savoir changer la valeur d’un GPIO via le sysfs de Linux (ou coder un truc bidon en Arduino) suffit à être ingénieur embarqué professionnellement. Alors que comme tout domaine, en particulier en informatique, il y a bien des trucs à connaître que ce soit au niveau de l’électronique (lire un schéma et savoir toucher un oscilloscope est un minimum), des langages bas niveaux et de leurs spécificités (le C et le C++ sont assez incontournables) que de savoir manipuler une toolchain pour son environnement de travail et savoir comment fonctionne le noyau en gros.

Cela s’apprend oui, mais pas en 3 jours. Faut envisager ce genre de reconversion dans le temps long, sauf si tu sors d’études qui traitaient déjà du sujet.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+2 -0

Sans vouloir bercer dans le commentaire type "vieux con élitiste" et ne connaissant pas non plus ton background d’informaticien, je tiens juste à préciser que le dev' embarqué ça ne s’improvise pas sur un coup de tête (tout comme on devient pas non plus dev web ou admin réseau du jour au lendemain). Il te faudra connaitre ou apprendre des choses en électroniques ainsi que quelques aspects propre au matériel embarqué.

Dépend d’où. Je reviens d’un mandat à faire du Yocto pour une boîte à destinations d’avions. Même dans ce cas il n’y a pas forcément besoin de connaissances relatives à l’embarqué pour des postes de QA, de dev d’interfaces, etc. Tu peux travailler dans l’embarqué sans être dev embarqué :)

Bref, un peu HS

+0 -0
Auteur du sujet

Merci à tous pour vos réponses et désolé pour le délai.

C’est le fait de regarder un écran qui te dérange ? d’être dans un bureau ? ou de ne pas avoir d’interaction sociale ?

A-312

Je dirais les trois. Être derrière un écran et dans un bureau implique à la fois un certain immobilisme, alors que j’apprécie faire de l’activité physique (ne serait-ce que se déplacer), et une faible interaction avec l’environnement, que ce soit les objets, la nature ou les personnes.

Ayant bossé dans l’industrie et l’aéronautique, les objets où s’intègrent mes développements étaient bien trop grands pour que tu y aies accès régulièrement. En général tu bosses dans ce cas avec un périphérique qui simule les entrées / sorties. Tu ne vois le résultat final que lors de la livraison ou lors d’un test intermédiaire.

Et sur des systèmes plus modestes ? Je ne pense pas que ce soit représentatif du monde du travail, mais j’ai travaillé avec mon oncle agriculteur sur un projet de domotique. J’étais amené à l’aider à construire le système physique et j’interagissais avec ce système pour faire mes tests. Mais j’imagine que dans la vraie vie, les rôles sont plus cloisonnés que ça.

Pour allier, comme tu le présentes l’agriculture à l’informatique… Pourquoi ne pas envisager des solutions autour de l’embarquée ?

Justement, j’envisage cela. Mais comme le fait remarquer @Eskimon, il y a un pas entre bidouiller avec son Arduino et travailler dans le domaine. Or je ne suis pas sûr d’être intéressé par les aspects plus poussés de l’informatique embarquée.

Enseigner peut être une bonne idée.

Oui !

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).

Merci beaucoup pour ce long message explicatif. :)


En fait, peut-être que ma question est plutôt celle posée dans ce sujet : comment travailler dans l’informatique tout en conservant du temps libre pour faire autre chose.

+0 -0

En fait, peut-être que ma question est plutôt celle posée dans ce sujet : comment travailler dans l’informatique tout en conservant du temps libre pour faire autre chose.

Ça c’est facile, il suffit de travailler à temps partiel !

+0 -0

Et sur des systèmes plus modestes ?

Pour l’avoir fait, si l’objet est de taille assez réduite tu l’as souvent… sur ton bureau avec éventuellement une salle pour faire des tests quand cela est justifié.

Comme l’a précisé Eskimon, en embarqué on évite de faire des tests grandeur nature trop souvent. Cela coûte cher, car cela demande du temps pour se déplacer, préparer le test, etc. Et si cela doit être fait souvent, tu as alors sans doute une personne dédiée à la tâche de réaliser les tests.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte