Orientation après la Terminale

→ **MyCalcs** profile · by **noelnadal** » 20 May 2015, 13:43

L'admission post-prépa est vraisemblablement facile, à en croire les statistiques.
Après, on revient au même problème : deux ans de prépa, te seront-elles profitables ?

EDIT : statistiques 2014 https://www.scei-concours.fr/statistiqu ... 14/mp.html (faut scroller un peu)

→ **MyCalcs** profile · by **Ti64CLi++** » 20 May 2015, 13:46

Ok, merci beaucoup pour toute ses réponses.

→ **MyCalcs** profile · by **Plokki** » 20 May 2015, 14:50

Merci beaucoup pour ces réponses même si la question n'est pas de moi

puisque je me trouve un peu dans la même situation

Effectivement, après avoir appris le Ti-basic et vu les possiblités je me suis dit que je ferais bien codeur de jeu vidéo donc je me suis renseigné et j'ai effectivement vu le côté "exploitation" des employés... Autant dire que ça ma refroidit pour le jeu vidéo mais pas pour la programmation

Mon choix se porterait sur une école d'ingénieur car j'ai un bon niveau scolaire. Il y était surtout question de "systèmes embarqués":

Levak wrote:Je n'ai pas fini par faire dans le monde du jeu vidéo, mais dans celui de l'embarqué temps réel, en faisant une école d'ingénieur en informatique.

Pourrais-tu m'expliquer en quoi consiste ton métier, ses points forts et faibles et tout

? Parce que ça reste très abstrait pour moi, merci d'avance

→ **MyCalcs** profile · by **Lionel Debroux** » 20 May 2015, 15:07

"Programmation pour systèmes embarqués" (c'est également mon goût, c'est comme ça que j'ai commencé et fait ma formation initiale en informatique) signifie programmation sous contraintes de puissance de calcul, de taille de RAM, de quantité de stockage persistant, de consommation électrique, de temps de réponse (soit réponse très rapide, soit temps de réponse garanti court, ce qui n'est pas la même chose), etc. d'ordinateurs de moindre puissance, voire d'ordinateurs aux capacitées très limitées (noeuds de capteurs très basse conso, par exemple).

Bien sûr, on a toujours des contraintes de puissance de calcul, consommation mémoire, etc. - mais sur plate-formes non embarquées, elles sont faibles.

La définition de l'embarqué sera peut-être plus claire en prenant des exemples:
* les microcontrôleurs embarqués tournant à quelques MHz, avec quelques centaines de KB de RAM / Flash, sont clairement des systèmes embarqués. Autrement dit, toutes les calculatrices graphiques du marché, tous constructeurs confondus, sont des systèmes embarqués. Les noeuds de capteurs, et autres participants à l'Internet des objets (IoT) aussi;
* la Raspberry Pi, et les boards consumer / industrielles moins puissantes, sont habituellement considérées comme de l'embarqué, même si les contraintes de puissance / mémoire sont de plus en plus faibles;
* à mon sens, les boards ARM les plus puissantes, les smartphones et tablettes récents sont du faux embarqué. Il y a certes des contraintes de consommation électrique, mais quand on a un processeur 4+ coeurs clocké à 2+ GHz, 2+ GB de RAM, 16+ GB de Flash, pour la plupart des usages, on n'est plus embêtés par la capacité de calcul / stockage;
* les desktops et laptops ne sont pas de l'embarqué.
* les serveurs multi-coeurs de data center non plus, même certains designs récents basse consommation qui se rapprochent au mieux du faux embarqué sus-mentionné (par exemple, Scaleway C1: Cortex-A9 quad @ 1.3 GHz, 2 GB RAM).

Les spécificités de la programmation embarquée sont multiples: impossibilité d'utiliser certains algorithmes trop gourmands en CPU / RAM, impossibilité de faire tourner une distro Linux complète (même si ladite distro Linux prend un à deux ordres de grandeur moins de place que Windows), nécessité de passer davantage de temps sur l'optimisation vitesse / taille, et j'en passe.

Tout comme les autres métiers, le métier d'informaticien change avec le temps... mais il change beaucoup plus vite, et de plus en plus vite. Il est moins important de savoir bien coder qu'auparavant. Grâce à l'open source, le choix de technos prêtes à l'emploi est de plus en plus grand, donc il faut choisir des blocs de construction selon divers critères et les assembler pour construire des ensembles plus complexes.
Il est important de faire de la veille technologique.

→ **MyCalcs** profile · by **Lionel Debroux** » 21 May 2015, 18:22

Dans l'image

(vue sur https://medium.com/@nodesource/node-and-arm-b5e3eebf449 à travers la newsletter Scaleway, bref) on voit un processeur pour système embarqué.

→ **MyCalcs** profile · by **Plokki** » 21 May 2015, 18:43

Merci pour les précisions je ne voyais pas ça comme ça

Tu pourrais m'expliquer un peu plus en détail ton travail au quotidien s'il te plaît ?

Si j'en crois l'image cette petite puce est donc pas beaucoup moins puissante que ma calculatrice non ?

→ **MyCalcs** profile · by **Lionel Debroux** » 21 May 2015, 19:10

La puce est un peu moins puissante que le CPU des calculatrices graphiques, en particulier elle a beaucoup moins de mémoire. En revanche, associée à quelques périphériques externes, elle est bien plus puissante qu'il ne suffit pour une calculatrice 4 opérations, et un certain nombre de calculatrices scientifiques.

Je vais commencer par décrire les projets sur lesquels j'ai travaillé et que je peux décrire (secret professionnel, évidemment), avant de décrire plus précisément les activités que ça recouvre

J'espère qu'après ce post, tu as une meilleure idée de ce qu'un informaticien fait au quotidien. Je peux essayer de donner des détails supplémentaires.
Bien sûr, je ne fais pas toutes les activités sous-mentionnées chaque jour, loin s'en faut. Et ne t'inquiète pas, on est loin d'apprendre tout ça à l'école. Il faut apprendre hors des études, et rester curieux en-dehors du travail.

Projets sur lesquels j'ai travaillé
Ca fait un peu plus de 7 ans réels que je travaille, et jusqu'à présent, j'ai travaillé chez trois employeurs, sur cinq projets. Les deux premiers employeurs étaient des labos de recherche, j'étais par conséquent en CDD. Les postes d'ingénieur de recherche en CDI nécessitent plus d'expérience que j'en avais à l'époque, et ils sont fort rares.

* dans le premier labo, pendant deux ans, j'ai commencé par du tutorial sur un environnement de programmation dite à composants en C (projet open source); rapidement, des limitations sont apparues, donc j'ai participé à l'amélioration de l'environnement d'exécution (C) et de la toolchain (écrite en Java).
Travail sous Linux, toolchain ciblée GCC, et à l'époque, il n'y avait pas grand chose d'autre (aussi facilement accessible) que x86 / x86_64. J'ai quand même compilé une fois les programmes avec GCC4TI, ce qui a permis de détecter et corriger des problèmes de portabilité, et je les ai exécutés sur une TI-68k, probablement émulée.

* dans le deuxième labo, j'ai participé à l'implémentation d'un middleware pour l'intelligence ambiante (oui, deux buzzwords), appliqué à la gestion du bâtiment. C'était également un projet open source. Passerelle (gateway) de récupération des données de capteurs, communication avec des prises CPL instrumentées capables de remonter des infos de conso et d'activer / désactiver leur sortie, envoi des données dans un vague système de traitement.
Personne n'a jamais vraiment utilisé ce qu'on a produit, que je sache - mais c'est le cas dans de nombreux projets financés par l'Europe. Et pour la petite histoire, j'ai rencontré une fois le père d'Adriweb par le boulot, puisqu'on est allés dans ce qui était à l'époque sa boîte

Travail principalement sous Linux avec Java/OSGi(TM), exécution de la gateway sur x86 / x86_64 / ARM / MIPS; pour les noeuds de capteurs (différents modèles), toolchains Windows ou Linux, et code C embarqué (bare metal, ou un peu de Contiki). L'exécution sur MIPS / ARM avait permis de voir à quel point notre gateway était lourde, j'ai fait une version non officielle simplifiée avec la même enveloppe fonctionnelle pour les cas simples (= tout ce qu'on a réellement codé pendant ce projet financé...) qui démarrait 15x plus vite et consommait 6x moins de mémoire...

* chez mon employeur actuel, je peux donner des infos sur le projet financé de R&D pour lequel j'ai recruté et sur lequel j'ai travaillé pendant plus de 3 ans, parce que certaines sont publiques. Entre autres, on a fait une démo publique en 2014 dans le cadre de l'organisme de financement public.
C'est un système de supervision industrielle se voulant être portable, moins passoire que les coûteuses offres commerciales habituelles (qui se distinguent régulièrement dans les résumés hebdomadaires de vulnérabilités par des CVE de CVSS très élevés, assez souvent exécution de code arbitraire) et léger. Donc Linux, pour la légèreté, la portabilité, l'absence de coûts de licence à moins d'utiliser une distro commerciale, et une relative sécurité (surtout si on utilise des kernels grsec, ce qu'hélas, ~0% des utilisateurs font); C++ avec librairie étendue de classes (il n'y a pas 36 bons choix), pour la vitesse d'exécution. Le projet (cross-)compile sur x86 (Debian "i386"), x86_64 ("amd64"), ARM hard-float ("armhf"), ARM soft-float ("armel"), ARM 64 bits AArch64 ("aarch64"), et MIPS ("mips"), autrement dit toutes les architectures importantes maintenant. Il a été testé sur de vraies machines représentant les 4 premières architectures.
Sur les deux autres projets plus récents, je ne peux pas donner d'infos. Disons que les deux sont sous Linux; le petit projet intermédiaire était plus proche du premier, et le troisième projet sur lequel je travaille actuellement est théoriquement un projet de R&D, technologiquement éloigné (langage d'implémentation et briques de base différents), de tout ce que j'avais fait jusqu'à maintenant, dans la ligne des buzzwords "cloud" et "big data".

Activités sur les projets sus-mentionnés
En plus des évidentes activités de lecture de code source existant, relecture du code a posteriori, création / modification / suppression de code source, test (plus ou moins développé et automatisé...) et debug, citons les activités suivantes, guidées par les exigences dites "non fonctionnelles" (voir plus bas), en respectant les délais (toujours trop courts) et les coûts, et bien entendu non exhaustives:
* système de construction de l'assemblage logiciel: définitions Maven pour Java, définitions de Makefiles ou pour les outils de plus haut niveau qui en génèrent (autotools, CMake, qmake, etc.) pour C/C++, et bien d'autres;
* conception ("design") des blocs de code avant de les coder et redécoupage / reconception lors du refactoring;
* conception de l'organisation et de la communication des petits morceaux de code source entre eux;
* éventuellement choix des technos et briques de base les plus adaptées. Il est hélas rare d'avoir la liberté de choisir toutes les technos les plus adaptées au fait de remplir la tâche au moment où le programme sortira et pendant les années qui suivront. (*)
* documentation du design / de l'implémentation / des tests, quand on peut faire (parce qu'on a le temps ou parce qu'on est obligés) ladite documentation;
* paramétrage du logiciel d'intégration continue;
* réalisation des définitions de déploiement (packaging, etc.);
* utilisation d'analyseurs statiques de code et correction des défauts remontés;
* installation et administration de machines réelles et virtuelles;
* installation, administration, configuration de routeur/firewall.

Deux des autres activités de ces projets auxquelles j'ai peu participé:
* conception d'une grosse application en sous-systèmes. C'est plutôt le rôle d'un architecte, ce qui nécessite une certaine expérience que je n'ai pas encore, bien entendu;
* les documentations des niveaux supérieurs de spécifications, la définition des exigences dites "non-fonctionnelles" (performance, portabilité, sécurité, sûreté, et deux douzaines d'autres, qui entrent bien entendu en contradiction les unes avec les autres, donc il faut faire des compromis), les analyses fonctionnelles, etc. sont plutôt le rôle des architectes, analystes fonctionnels, etc.

Même pour les programmeurs (qui ne représentent qu'un des groupes d'activités, certes un des plus importants, de l'informatique), la variété de langages d'implémentation, de plate-formes sur lesquelles les applications s'exécutent, de durée de vie des applications, est immense

*: dans le projet de R&D supervision industrielle, et dans une moindre mesure le petit projet intermédiaire, on avait le choix, et on s'est bien amusés à réfléchir, essayer et choisir, avant de faire. 4 à 3 ans après nos principaux choix techniques, ceux-ci restent pertinents: de nouvelles technos qui sont meilleures sur certains points sont apparues entretemps, mais on ne peut pas nous reprocher de nous être lancés dans des impasses techniques, et certains de nos choix sont encore meilleurs maintenant qu'à l'époque, à commencer par Linux.
En revanche, pour les autres projets, les environnements étaient / sont au moins partiellement imposés, par l'histoire (projet existant), par le client (qui a l'habitude de certaines technos, et beaucoup de clients n'aiment pas les technos récentes), par le management / financement (là, on est à la merci de choix politiques, par opposition aux choix techniques) / etc. Ca ne veut bien entendu pas dire que toutes les contraintes engendrent de mauvais choix; mais on peut presque toujours trouver mieux que les technos imposées.

→ **MyCalcs** profile · by **Lu_Lu54** » 22 May 2015, 16:23

Plokki wrote:Effectivement, après avoir appris le Ti-basic et vu les possiblités je me suis dit que je ferais bien codeur de jeu vidéo

je te souhaite d'en apprendre un peu plus que moi pour poursuivre ton rêve

→ **MyCalcs** profile · by **Plokki** » 22 May 2015, 21:45

Merci pour ce descriptif très intéressant même si je dois avouer ne pas avoir tout compris, en particulier dans la partie "projets" à cause du langage technique qui m'est assez obscur.
Voici donc ce que j'ai compris (corrige moi si je dis des bêtises) ainsi que quelques questions:

-Tes employeurs peuvent être publics (R&D) ou privés mais par quels biais te proposent-ils un projet ? Une sorte d'agence d'intérim pour informaticien ?

-Travailles-tu seul ou en équipe ? Si tu es en équipe, combien de personnes approximativement et comment les tâches sont réparties ?

-Comment la rémunération/difficulté/temps et coût d'un projet est elle estimée et par qui ?

-Tes projets ont principalement tourné autour des échanges et traitement de données, y a-t-il d'autres grands domaines ?

-Tu es amené à utiliser de nombreux supports et langages de programmation, combien en maîtrises-tu et à quel niveau (innitié, pro, guru

) ? As-tu une spécialité ou bien la popyvalence est de mise ?

-J'imagine que ton travail présente un certain stress en cas de dépassement de délais à cause de phases de débuggage intempestives, comment gérer/prévoir ça ?

Voilà, j'espère que tu pourras me renseigner

>Lu_Lu54: Je maîtrise déjà pas mal l'Axe et je compte me mettre au java pendant les vacances d'été

→ **MyCalcs** profile · by **Lionel Debroux** » 23 May 2015, 07:57

-Tes employeurs peuvent être publics (R&D) ou privés mais par quels biais te proposent-ils un projet ? Une sorte d'agence d'intérim pour informaticien ?

Il y a effectivement les petites annonces et plate-formes habituelles en ligne d'offres d'emploi, mais pour les bac+5 en informatique, 40-50% des offres dans le privé (oui, c'est un pourcentage énorme) ne sont pas postées publiquement, pour des raisons comme "ne pas donner des infos aux concurrents", et aussi "la recommandation par quelqu'un que je connais est plus efficace qu'un CV générique". Dans le public, les offres sont postées publiquement.
* si je me souviens bien, le poste dans le premier labo m'avait été proposé par mon binôme, auquel il avait été proposé, mais il était déjà pris ailleurs. J'ai passé l'entretien, et j'ai été retenu;
* le poste dans le deuxième labo était proposé par un des copains d'un de mes chefs du premier labo. Là aussi, j'ai passé l'entretien, et j'ai été retenu;
* j'ai eu connaissance du poste avec lequel je suis entré chez mon troisième et actuel employeur à travers la mailing list des anciens étudiants de notre classe de M1 / M2P. Il est probable que l'offre d'emploi ait été postée publiquement, vu que c'était un projet financé par un organisme public.

-Travailles-tu seul ou en équipe ? Si tu es en équipe, combien de personnes approximativement et comment les tâches sont réparties ?

Toujours en équipe pour moi, même si dans les labos, la (grande) majorité des gens avec lesquels je travaillais directement n'étaient pas physiquement sur le même lieu de travail. Dans le privé, ça aurait été pareil si j'avais été sur un autre projet; sur le projet actuel, d'autres personnes Il y avait des réunions physiques (pas forcément dans la région ou même le pays, dans le cas d'un projet européen...) ou réunions téléphoniques (teleconferences, "telcos") plus ou moins fréquentes (plus rares dans le premier emploi).
Pour l'instant, j'ai travaillé seulement dans de petites équipes, 3-7 personnes. Ce n'est pas le cas de tout le monde, il y a des équipes de plusieurs dizaines de personnes. Même en temps libre, dans la communauté TI ou dans la communauté de factorisation d'entiers (qui est une conséquence de la participation à la première), j'agis habituellement en collaboration avec d'autres personnes.
Pour certains profils et certaines expertises, il existe des emplois de consultant plus solitaires.

-Comment la rémunération/difficulté/temps et coût d'un projet est elle estimée et par qui ?

C'est variable

Dans le public, c'est particulier. C'est plutôt une question de budget fixe, et de temps. L'organisme offre des postes pour des ingénieurs tout juste diplômés et les équipes qui en ont besoin peuvent candidater; le budget accordé pour le projet financé fait qu'on peut payer un thésard pendant 3 ans + un ingénieur pendant tant de temps (ou le projet est financé de telle sorte à payer un thésard pendant 3 ans + un ingénieur pendant tant de temps).
Dans le privé... pour faire les choses dans le bon sens, c'est plutôt un job d'architecte expérimenté, qui estimera les parties, et en déduira le temps et l'expertise nécessaire, d'où le coût est déduit. Dans le mauvais sens, en particulier dans les grosses structures, c'est l'interférence du marketing, l'avant-vente et le management sur les coûts et délais dans les deux sens: "il faut que ça soit fait pour telle date et vous vous démerdez sans forcément avoir les moyens ou compétences", "il faut que ça ne coûte pas plus que N pour avoir une chance d'être retenu par le client, donc on ne va pas tenir compte de l'évaluation de l'architecte; si on rentre ce projet sous-chiffré, vous vous démerderez".
Les éditeurs de logiciels sont un type différent des sociétés de service en ingéniérie informatique (les fameuses SSII), que je connais moins bien. Ce sont souvent des structures plus petites, vendant et faisant évoluer peu de produits pour des clients. Si la boîte arrive à vivre, ça peut être sympa.

-Tes projets ont principalement tourné autour des échanges et traitement de données, y a-t-il d'autres grands domaines ?

Bien vu: fondamentalement, l'informatique consiste précisément à traiter des données de manière automatisée (sur la base d'algorithmes, implémentés et assemblés - ici, j'utilise le mot "assembler" dans le sens lier les morceaux entre eux - par les programmeurs), et de plus en plus souvent, échanger des données entre systèmes informatiques: développement des communications Machine To Machine (M2M) dans l'Internet of Things (IoT).
Dans les métiers peu programmatiques de l'informatique (par exemple le design d'interfaces graphiques, ou certains types de graphisme), il y a moins de traitement.
Une petite parenthèse sur l'IoT, c'est ma sensibilité sécurité informatique qui s'exprime: les retours d'expérience de ces dernières années montrent qu'il est encore (beaucoup) moins sécurisé, et donc plus dangereux, que l'informatique Internet, bureautique et mobile actuelle. On voit très souvent de nouveaux produits bourrés de failles gravissimes connues depuis longtemps. Bref, de très gros ennuis - et donc de très gros coûts - à venir, tout ça parce qu'on ne prend pas le temps de faire correctement les choses en amont... Mieux vaut éviter la domotique (sauf quand elle est utile, par exemple pour les handicapés, même si en général, ceux qui ont vraiment besoin de la domotique au quotidien ne peuvent pas se la payer...) et vivre hors des smart cities

-Tu es amené à utiliser de nombreux supports et langages de programmation, combien en maîtrises-tu et à quel niveau (innitié, pro, guru ) ? As-tu une spécialité ou bien la polyvalence est de mise ?

En premier lieu, je reste un programmeur C/C++, et plutôt des choses non visibles. Je n'aime pas faire les interfaces graphiques, et à mon sens (hélas non partagé par le marketing, management, financement... mais ce n'est pas moi qui ai tort), un backend fait comme il faut est plus important à moyen-long terme, pour la réduction des coûts, que la peinture sur merde (jolie interface graphique sur un château de sable). Le château de sable coûte cher à maintenir sur le moyen-long terme, parce qu'il est en général mal architecturé, il a plus de failles de sécurité, etc.
C'est également visible dans les projets open source que je maintiens hors du travail (quand j'ai du temps et de l'énergie): je travaille beaucoup, beaucoup plus sur libti* que sur les front-ends graphiques gfm et tilp; dans GCC4TI, je ne travaille plus beaucoup parce qu'il n'y a plus beaucoup d'utilisateurs, mais j'ai travaillé sur la librairie, les morceaux de la toolchain, plutôt que sur l'IDE.

Mais une certaine polyvalence est de mise, encore plus maintenant qu'auparavant. Pour la programmation, il faut bien connaître au moins un langage de script, où il est plus productif (en temps de développement) de prototyper et d'écrire certains traitements de données. Historiquement, le langage de script standard était Perl, mais il est moins populaire maintenant, au profit de Python et JavaScript, par exemple.
Connaître plusieurs langages et plusieurs familles de langages permet de faire de vrais choix (entre plusieurs possibilités), plutôt que des choix par défaut (parce qu'on ne connaît que ça).
Le métier d'informaticien évolue de plus en plus vite, vers la réalisation de tâches toujours plus complexes en un temps toujours plus court (et donc pas toujours de mieux en mieux...). Il consiste bien plus qu'avant en l'assemblage de briques existantes (et pourquoi pas la contribution aux briques existantes, vu qu'elles sont en général open source - sur les 10 dernières années, aucune nouvelle techno disruptive n'est closed-source).

-J'imagine que ton travail présente un certain stress en cas de dépassement de délais à cause de phases de débuggage intempestives, comment gérer/prévoir ça ?

Les délais et le stress peuvent en effet être générés par le debug intempestif, mais pour moi (je ne prétends pas que tout le monde pense ainsi), il y a pire: le projet avec des deadlines trop serrées et mal échelonnées dans le temp, tout ça parce qu'il faut MONTRER POUR VENDRE ET FAIRE RENTRER DES SOUS. Si.
On n'a pas le temps de se plonger suffisamment dans le sujet, de lire suffisamment de choses sur le domaine, d'expérimenter et de faire les bons choix techniques pour le moyen-long terme. Du coup, il faudra refaire plus tard (ou du moins, essayer, parce que la contrainte de faire en priorité des choses visibles restera). Nombre de marketeurs, managers et financeurs n'ont absolument aucune idée (auquel cas ils sont incompétents), ou n'ont aucune envie de tenir compte (auquel cas ils sont pleins de malice, au sens anglophone), du fait qu'il y a des choses difficiles à faire en arrière-plan pour que ce qui est visible ait une chance de bien fonctionner...
Faire ce qu'on nous demande de faire, plutôt que ce qu'il faudrait faire (pour pouvoir bien faire les choses sur le temps long, et ainsi réduire les coûts), est (pour moi, là encore) une source bien plus grande de stress que devoir debugger intempestivement.