LO
Informatique
Vous forme à modéliser un problème assez précisément pour qu'une machine puisse l'exécuter — et à raisonner sur ce qui se passe quand elle le fait à grande échelle, en cas de panne, et avec quelqu'un qui vous attaque.
Un chiffre unique pour toute une filière cacherait ce qui compte : ce diplôme forme plusieurs compétences distinctes, et elles ne vont pas toutes dans le même sens. L'automatisation agit sur des tâches : toute évaluation vit donc sur les pages métier ci-dessous — pas ici.
Écrit pour les diplômes d'informatique et de génie logiciel en quatre ans. Les cursus orientés recherche ou matériel diffèrent sensiblement.
Ce que ce diplôme forme réellement#
Pas la liste des cours — les compétences en dessous, et si chacune vaut plus ou moins qu'avant.
Modéliser un problème avec précision
Vaut plus qu'avantTransformer ce qu'une personne a décrit vaguement en une spécification sans cas indéfini.
La génération est en aval de la spécification et amplifie une spécification fausse plus vite qu'une personne ne l'aurait fait. Celui qui écrit la spécification détermine désormais davantage le résultat que celui qui écrit le code.
Raisonner sur la défaillance
Vaut plus qu'avantSavoir ce qui casse sous la concurrence, la panne partielle et une entrée inattendue — avant que cela casse.
C'est là que le plafond du code généré se voit le plus clairement. Un code fluide mais faux sous charge est indiscernable d'un code correct jusqu'à ce qu'il soit en production.
Lire un système inconnu
Vaut plus qu'avantTenir en tête assez du code d'un autre pour savoir quelle observation serait décisive.
À mesure qu'une plus grande part du code est produite par machine, une plus grande part du métier consiste à lire du code que personne n'a écrit à la main. Relire un code plausible mais faux est une compétence distincte, et nouvellement centrale.
Écrire du code routinier
Vaut moins à lui seulProduire des implémentations correctes et idiomatiques de choses bien spécifiées.
Bien spécifié, fortement représenté dans les données d'entraînement, et vérifiable immédiatement en l'exécutant — le cas le plus solide pour la génération de code. Mais notez ceci : on ne peut pas juger un code qu'on n'aurait pas pu écrire, donc cela reste un prérequis même quand cela cesse d'être un produit.
Les fondamentaux
Se maintientLa complexité, les structures de données, les modèles de concurrence, la façon dont une machine exécute réellement.
La partie du diplôme qui se démode le plus lentement et que l'on n'attrape pas dans un tutoriel. C'est elle qui permet de raisonner sur un système qu'on n'a jamais vu.
Où cela peut mener#
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.
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.
Ce qu'il faut ajouter en dehors des cours#
Il s'agit de ce qui manque couramment aux diplômés en pratique — non d'affirmer que votre école ne l'a pas enseigné.
Du temps passé dans un dépôt où il y a un enjeu réel — un stage, un projet ouvert dont des gens dépendent, n'importe quoi où se tromper a une conséquence. Les projets jouets ne peuvent pas enseigner le jugement parce que rien n'y est en risque.
Relire le code des autres, y compris le code généré, délibérément et régulièrement. C'est la compétence qui manque au marché et celle que l'école évalue le moins.
Écrire. Documents de conception, comptes rendus d'incident, explications. Les ingénieurs qui avancent sont ceux dont les autres peuvent suivre le raisonnement.
Ce semestre#
Une ou deux actions, chacune produisant quelque chose que vous pouvez montrer à quelqu'un. Pas une liste de lectures.
Commencez le dossier hebdomadaire de relectures de code. Quatre entrées à la fin du semestre est un meilleur signal que n'importe quel certificat.
Lisez un système en production de bout en bout dans un domaine où la justesse coûte cher. La profondeur en un endroit vaut mieux que la largeur sur cinq.
Questions fréquentes#
Oui, mais pour une autre raison qu'il y a cinq ans. Le diplôme valait parce qu'il permettait de produire du code ; sa valeur est maintenant qu'il permet de juger du code — et on ne peut pas juger ce qu'on n'aurait pas pu écrire. Ce qui a réellement changé, c'est le marché de l'emploi à l'entrée : le travail routinier qui payait les juniors pendant qu'ils développaient leur jugement est précisément la part qui s'automatise. La formation fonctionne donc toujours, mais l'ancien arrangement où votre premier emploi vous formait aux frais d'un autre s'affaiblit. Prévoyez explicitement cet écart au lieu de supposer que le premier emploi le comblera.
L'informatique est le cas singulier : les outils sont excellents précisément dans ce que le diplôme apprend à produire, et l'emploi d'entrée auquel il mène est un emploi où plusieurs employeurs ont publiquement réduit les embauches. C'est un argument réel, et ce n'est pas un argument pour partir — c'est un argument pour entrer avec un plan pour atteindre le travail de jugement, parce que le barreau du code routinier qui vous y portait s'est aminci.
Il vaut la peine quand il change ce pour quoi vous pouvez être recruté — recherche, systèmes, une spécialité à peu de praticiens — et il ne vaut pas la peine comme façon d'attendre que le marché des jeunes diplômés se raffermisse. Un master qui enseigne les mêmes compétences de production un niveau au-dessus affronte les mêmes outils. Examinez le laboratoire ou l'équipe précise, pas le nom du diplôme.
Quelque chose que vous avez débogué sans l'avoir écrit. Lire un code fluide mais faux avec assez d'attention pour trouver ce qui est cassé avec assurance est la tâche que ce site signale comme nouvellement centrale, et c'est la seule chose qu'un portfolio de projets générés ne peut pas démontrer. Une vraie contribution à un dépôt que vous n'avez pas commencé vaut mieux que cinq projets personnels achevés.
Méthode#
Les évaluations portent sur des tâches, non sur des filières. Suivez n'importe quelle direction ci-dessus jusqu'à sa page métier pour voir quelles tâches changent, quelle est la force des preuves, et ce qu'elles ne montrent pas encore.