LO
Informatique — où cela mène
Plusieurs directions, jamais une seule. Chacune dit ce que votre formation réemploie, ce qui manque généralement aux diplômés, les conditions d'entrée réelles, et une chose que vous pouvez tester ce semestre. Cette page n'évalue pas la filière : l'évaluation porte sur la tâche, alors suivez n'importe quelle direction jusqu'à sa page métier.
Où cela peut mener#
L'ingénierie logicielle, en y entrant délibérément
analyse au niveau de la tâche →- Ce qui se transfère
- Tout — c'est la voie directe.
- Ce qui manque généralement aux diplômés
- Non de la connaissance mais des preuves de jugement. Le premier emploi traditionnel enseignait le jugement en vous payant pour écrire du code routinier pendant deux ans ; cet arrangement s'affaiblit, donc il faut démontrer une pensée de niveau relecture avant que quiconque ne vous la demande d'habitude.
- La réalité de l'entrée
- Le barreau du bas de l'échelle est plus étroit qu'avant ; le haut est intact. Lisez la page du métier — le partage entre l'entrée de carrière et le niveau senior y est plus net que dans tout autre métier du premier lot.
Prenez une demande de fusion générée — la vôtre ou celle d'un projet ouvert — et écrivez une relecture qui trouve un vrai problème, avec le raisonnement explicité. Faites-le chaque semaine et gardez-les. Ce dossier vaut plus qu'un tutoriel supplémentaire terminé.
Les domaines où se tromper coûte cher
analyse au niveau de la tâche →- Ce qui se transfère
- Le raisonnement sur la défaillance et les fondamentaux, là où un humain reste fermement dans la boucle : paiements, sécurité, intégrité des données, infrastructure.
- Ce qui manque généralement aux diplômés
- De la profondeur dans un domaine précis, que seul le temps produit. La plupart des diplômés ont de la largeur et aucune profondeur, ce qui est exactement l'inverse de ce que demande cette voie.
- La réalité de l'entrée
- Moins d'offres d'entrée, mais celles qui existent sont moins exposées et mieux payées. On y arrive souvent après un an ou deux ailleurs plutôt que directement.
Choisissez un de ces domaines et lisez de bout en bout la façon dont un vrai système en production le traite — une bibliothèque ouverte de paiement ou d'authentification — jusqu'à pouvoir expliquer ses modes de défaillance à un camarade.
Entre l'ingénierie et le problème
- Ce qui se transfère
- La modélisation du problème plus la capacité à lire un système, appliquées là où la valeur est de comprendre à la fois la machine et ce qu'une personne en attend : ingénierie de solutions, expérience développeur, produit technique.
- Ce qui manque généralement aux diplômés
- La communication traitée comme une compétence de premier plan et non comme une qualité secondaire — écrire une documentation qu'on peut réellement suivre, et mener une conversation avec quelqu'un qui n'a pas votre vocabulaire.
- La réalité de l'entrée
- Rarement affiché au niveau diplômé, on y entre d'habitude latéralement après un temps d'ingénierie. Il vaut la peine de savoir tôt que cela existe pour construire dans cette direction.
Rédigez la documentation de quelque chose que vous avez construit, confiez-la à quelqu'un qui ne connaît pas, et regardez où il se bloque sans l'aider. Ce silence est la leçon.
La pensée d'ingénieur dans un domaine non logiciel
- Ce qui se transfère
- Toute la boîte à outils, appliquée là où presque personne ne sait à la fois comprendre le domaine et construire. Cette combinaison est rare et n'affronte pas la génération de face.
- Ce qui manque généralement aux diplômés
- Le domaine lui-même, à reprendre presque de zéro — et la patience d'une première année qui donne l'impression de reculer.
- La réalité de l'entrée
- Aucun parcours standard, ce qui coupe des deux côtés : pas de file d'attente à rejoindre, mais personne qui recrute pour cela non plus. Cela part d'habitude d'un lien personnel avec le domaine.
Trouvez une personne d'un domaine non logiciel avec un problème répétitif, et construisez la plus petite chose qui l'aide réellement. Une personne qui s'en sert vaut mieux que cent étoiles sur GitHub.
Le test et l'ingénierie de la qualité
analyse au niveau de la tâche →- Ce qui se transfère
- Le raisonnement sur la défaillance, transformé en métier : trouver comment un système casse avant qu'un utilisateur ne le fasse, et bâtir le harnais qui continue de le prouver.
- Ce qui manque généralement aux diplômés
- Les diplômés arrivent d'habitude capables d'écrire des tests pour du code qu'ils ont écrit eux-mêmes, ce qui est le cas facile. Le métier, c'est tester le code écrit par un autre, sous un délai qui appartient à cet autre.
- La réalité de l'entrée
- L'un des points d'entrée les plus ouverts du logiciel, et souvent traité injustement comme un point d'entrée mineur. Lisez la page du métier avant de décider : la génération de tests est l'une des tâches les plus documentées de ce site, et ce que ces preuves changent, c'est quelle moitié du métier reste.
Prenez le projet d'un camarade que vous n'avez pas écrit, et trouvez trois façons de le casser qu'il n'avait pas anticipées. Notez laquelle des trois une suite de tests générée aurait attrapée.
Mettre l'IA en production dans une entreprise
analyse au niveau de la tâche →- Ce qui se transfère
- La lecture d'un système plus la modélisation du problème, appliquées à une entreprise qui a acheté les outils et a maintenant besoin de quelqu'un pour décider ce qu'ils peuvent faire sans surveillance.
- Ce qui manque généralement aux diplômés
- Les diplômés sous-estiment que l'essentiel est organisationnel — faire s'accorder deux services, et être là quand la chose se trompe — plutôt que technique.
- La réalité de l'entrée
- Rarement un premier emploi, et réellement difficile à lire de l'extérieur : le métier est assez jeune pour que ce site marque sa confiance comme faible, et l'essentiel de ce qui s'écrit à son sujet est écrit par des gens qui vendent des services de mise en œuvre de l'IA. C'est une raison d'aller voir plutôt qu'une raison de l'éviter.
Choisissez un outil dont une association ou un laboratoire dépend réellement, et écrivez une page sur ce qu'il décide actuellement tout seul et ce qui devrait exiger une personne. Montrez-la au responsable de cet outil et voyez quelle ligne il contestera.
La couche que les gens touchent vraiment
analyse au niveau de la tâche →- Ce qui se transfère
- La modélisation du problème, au seul endroit où les cas indéfinis sont visibles par un inconnu : les états que personne n'a dessinés — vide, à moitié chargé, hors ligne, l'erreur qui arrive pendant que l'utilisateur tape encore.
- Ce qui manque généralement aux diplômés
- L'accessibilité, qu'un diplôme d'informatique n'enseigne presque jamais et qui, dans beaucoup de marchés, est une obligation légale et non une délicatesse. Notez ce que cela signifie pour cette voie : la partie que le diplôme a sautée est celle qui a une loi derrière elle.
- La réalité de l'entrée
- Le point d'entrée le plus large du logiciel, et celui où une démonstration d'interface générée fait le plus peur à regarder. Lisez la page du métier avant d'en tirer une conclusion : ce qui se génère bien, c'est le premier écran, et le reste du métier, ce sont de vrais appareils, de vrais réseaux, et les composants sur lesquels tous les autres construisent.
Prenez une interface que vous avez construite et utilisez-la de bout en bout au clavier seul, sans souris. Notez l'étape où vous vous êtes bloqué. Puis corrigez cette étape — vous venez de faire la partie de ce métier qui ne se génère pas.
Les tuyaux, et qui répond de ce qui en sort
analyse au niveau de la tâche →- Ce qui se transfère
- Le raisonnement sur la défaillance, dirigé vers le mode de défaillance que ce diplôme apprend à attendre et auquel presque personne ne pense : celui où rien ne lève d'erreur et où le chiffre est simplement faux.
- Ce qui manque généralement aux diplômés
- Les diplômés ont écrit des requêtes ; ils n'ont pas maintenu quelque chose qui casse à 3 heures du matin parce qu'un système en amont a changé un champ sans le dire à personne. Et personne ne leur a encore demandé de dire, en une phrase et de façon engageante, ce que veut dire un chiffre.
- La réalité de l'entrée
- Une porte plus large que celle de l'apprentissage automatique et bien moins encombrée, en partie parce que c'est moins prestigieux et en partie parce que ce travail ne devient visible qu'en échouant. La page du métier dit franchement que sa première tâche — construire le pipeline — est celle qui s'automatise le plus vite ; ce qui reste est la part où quelqu'un doit répondre de la définition.
Construisez un pipeline qui tourne tout seul chaque jour, puis introduisez délibérément une ligne fausse en entrée et regardez si quelque chose vous le signale. La première fois, pour la plupart des gens, rien ne le signale — ce silence est tout le métier en une expérience.
Des systèmes dont le comportement est appris
analyse au niveau de la tâche →- Ce qui se transfère
- Les fondamentaux et le raisonnement sur la défaillance, sur des systèmes dont personne ne peut expliquer ligne à ligne pourquoi ils ont fait ce qu'ils ont fait — donc le raisonnement doit être statistique plutôt que mécanique.
- Ce qui manque généralement aux diplômés
- La conception d'expériences et assez de statistiques pour se méfier de son propre résultat. Et une chose que les cours énoncent rarement : un modèle qui améliore la métrique hors ligne et empire pour les personnes sur qui il est utilisé est le cas normal, non un accident.
- La réalité de l'entrée
- Deux portes différentes qu'on appelle de la même façon. Les postes à saveur recherche sont étroits, très majoritairement de niveau master ou doctorat, et ce sont ceux auxquels tout le monde postule. La porte large, c'est le travail appliqué par-dessus des modèles achetés, qui grossit et ne s'annonce pas sous ce titre. La page du métier partage le travail de la même façon : entraîner un modèle est la tâche qui s'automatise le plus vite, décider ce qui compte comme assez bon est celle qui ne s'automatise pas.
Entraînez quelque chose sur un jeu de données public, puis notez où vous attendez qu'il se trompe avec assurance — et allez construire ces entrées jusqu'à ce qu'il se trompe. Décider ce qui compte comme assez bon, et se prouver à soi-même que ce n'est pas le cas, est la moitié de ce métier que personne ne peut confier à un outil.