Développeur côté serveur

Des recommandations de l'agence nationale britannique de cybersécurité, rédigées par l'un de ses architectes de sécurité principaux, qui placent le développement assisté par l'IA sur un spectre allant du code entièrement généré au code manuel. Elles conseillent de glisser vers le manuel lorsqu'on construit une logique d'authentification ou d'autorisation, qu'on traite des données personnelles sensibles, qu'on manipule des secrets, des jetons ou des identifiants de connexion, ou lorsque les conséquences d'une faille de sécurité seraient importantes. Ce sont des conseils, non une règle contraignante, et ils n'interdisent pas d'utiliser l'IA pour le code de sécurité ; ils ne donnent aucun chiffre sur la manière dont les développeurs travaillent réellement.

Un échec, un retour en arrière, une réglementation ou un coût freine l'adoption. Cela peut abaisser une appréciation ou élargir son incertitude.

Le même recensement : 20 questions fixes posées à toutes les agences qui déclarent au titre d'une obligation légale, chacune répondue par Oui ou Non, avec le produit nommé et les licences données par tranches. Générer du code avec l'IA est à Oui pour 31 sur 45, septième des 20. Ce qui donne à cette ligne plus de valeur que son décompte, c'est la colonne du produit, car les outils nommés n'existaient pas il y a trois ans : GitHub Copilot à l'Agriculture, aux Anciens combattants, à la SEC et dans une douzaine d'autres, Claude Code à l'Intérieur, Poolside à la Sécurité intérieure et au Travail, Codex à l'Office de gestion du personnel, Amazon Q Developer à la Santé. À comparer avec la ligne réservation de voyages du même fichier, où la plupart des Oui nomment SAP Concur : sur cette question-là, les agences désignaient largement une plateforme qu'elles avaient déjà, et sur celle-ci non. Trois limites. Une tranche de 10 000 à 50 000 à l'Énergie ou à l'Agence de protection de l'environnement est une licence d'entreprise qui répond aussi à d'autres lignes de ce fichier : ce n'est donc pas un décompte de personnes écrivant du code avec elle. Un Oui, c'est l'employeur déclarant qu'il dispose de l'outil, pas une mesure de la quantité de code qu'il écrit ni de ce qui en est conservé. Et la question dit code sans dire back-end ou front-end, ni depuis combien de temps celui qui l'écrit fait ce métier ; ce dossier est rattaché ici parce qu'écrire du code de service ordinaire est ce qu'est cette tâche, non parce que l'inventaire le dit.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

Un banc d'essai évalué par les pairs, composé de 392 tâches côté serveur, chacune étant un ensemble de points d'entrée à implémenter à partir d'une spécification, avec des tests fonctionnels et des exploits de sécurité de bout en bout, notamment sur un contrôle d'accès inadéquat et une autorisation incorrecte. Le meilleur modèle en justesse a atteint 62 % ; en moyenne, environ la moitié des programmes corrects produits par chaque modèle pouvaient être exploités ; et le meilleur modèle en code à la fois correct et sûr a atteint 35 %. Il s'agit de modèles de 2025 écrivant des back-ends entiers à partir d'une spécification, non de modifications au sein d'une base de code existante, et certains auteurs travaillent pour une entreprise qui construit des agents d'IA de programmation.

Un échec, un retour en arrière, une réglementation ou un coût freine l'adoption. Cela peut abaisser une appréciation ou élargir son incertitude.

Un article évalué par les pairs, écrit par des ingénieurs d'Uber, sur un outil intégré au propre flux de travail des développeurs d'Uber. En 18 mois, il a identifié 404 courses aux données reproductibles dans la base de code Go d'Uber et produit des correctifs pour 224 d'entre elles (55 %), et les développeurs en ont approuvé 193 (86 %) en relecture de code ; parmi les correctifs rejetés figuraient des correctifs jugés incorrects bien qu'ils aient passé les premiers tests. Uber ne vend pas l'outil. Il porte sur des courses aux données de bas niveau dans un seul langage et une seule base de code, non sur les transactions, l'idempotence, les reprises ou l'ordre entre services, et chaque correctif est passé par la relecture d'une personne.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

Des ingénieurs de Google décrivent leur propre usage des modèles de langage pour de grandes migrations de code internes. Dans une étude de cas, les identifiants de la base de code d'Ads (plus de 500 millions de lignes) devaient passer de 32 à 64 bits pour éviter des dépassements vers des valeurs négatives susceptibles de provoquer des pannes ; 80 % des modifications de code dans les changements intégrés ont été entièrement écrites par l'IA, dans la plupart des cas une personne a dû annuler au moins une partie des modifications du modèle, et les ingénieurs ont estimé que le temps total avait été réduit de 50 %. L'article indique que les relectures de code et les déploiements de modifications exigent toujours un opérateur humain. Google vend les modèles qu'il a utilisés. Il s'agit d'un changement de type dans le code de toute une base de code, non d'une migration de schéma de base de données en production.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

Une grande entreprise technologique, avec des chiffres qu'elle déclare elle-même et sans définir comment le « généré » est mesuré (autocomplétion ou fonctions entières). Le chiffre couvre tout le nouveau code de Google sans dire de quel type ; ce relevé est rattaché à cette tâche parce qu'écrire du code de service courant — gestionnaires, validation, appels entre services et leurs tests — est exactement cette tâche, et non parce que la déclaration désigne le travail backend. Elle ne dit rien sur les recrutements, et la relecture est restée aux ingénieurs.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

L'estimation interne d'Amazon sur l'ingénierie d'Amazon, publiée par l'entreprise qui vend l'outil — la partie qui fait le travail, celle qui le mesure et celle qui le vend sont la même, ce qui est dit ici parce que cela ne peut pas être vérifié de l'extérieur. L'entreprise publie aussi sa méthode : le temps économisé a été estimé à partir du nombre de dépendances Java migrées, en supposant un jour ou plus de temps de développeur par dépendance à la main. Notez ce qu'est la migration : une montée de version de langage a un compilateur et une suite de tests existante pour oracle, donc la réussite est vérifiable par machine à chaque étape — la forme la plus favorable possible pour ce genre d'automatisation, et non un résultat général sur le travail côté serveur. Et notez ce qui est affirmé et ce qui ne l'est pas : 4 500 années sont du travail non fait, par plus d'un millier de développeurs, sans aucune déclaration que l'un d'eux soit parti ou qu'un poste ait été supprimé.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

Un article évalué par les pairs, écrit surtout par des auteurs de Microsoft, sur un outil destiné aux ingénieurs d'astreinte qui traitent des incidents cloud. Son composant de collecte d'informations de diagnostic est déployé dans plus de 30 équipes de Microsoft depuis plus de quatre ans ; un composant de prédiction de cause racine utilisant un modèle de langage, après une phase préliminaire réussie, est activement déployé par une équipe de gestion d'incidents depuis plusieurs mois. Il aide au diagnostic ; il ne décide pas de ce qu'il faut annuler ou accepter, et Microsoft vend les modèles concernés.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

La moitié visible de ce métier — les points d'entrée et la plomberie — est la moitié exposée, et c'est ce pour quoi on vous aurait recruté. Les parties qui tiennent portent sur ce qui ne doit jamais arriver, et cela s'apprend en étant présent quand quelque chose est arrivé. Approchez une rotation d'astreinte plus tôt que cela ne paraît confortable.

Votre position est plus forte que celle de la page frontale sur la tâche la plus exposée, et la raison n'est pas que le travail soit plus dur — c'est que se tromper coûte cher et ne se voit pas, donc la responsabilité est concentrée. Guettez le mode de défaillance que cela crée : relire des modifications générées sur des systèmes où une erreur reste silencieuse pendant des mois.

Rester et se renforcer

Allez là où une erreur coûte cher

Paiements, grands livres, identité, tout ce qui a un régulateur — des domaines où une modification sans surveillance n'est pas permise, si bien que la relecture et la responsabilité sont financées plutôt que supposées.

Refaçonner le poste

Détenez la frontière que les agents peuvent franchir

Quelqu'un doit décider ce qu'une modification automatisée peut toucher dans un service où une erreur est silencieuse. Dans la plupart des équipes, personne n'a reçu cela, raison pour laquelle cela apparaît dans les revues d'incident plutôt que dans les fiches de poste.

Mouvement latéral

Passez au travail de données ou de plateforme

Le raisonnement sur la cohérence, la défaillance et le coût se transfère directement, et les deux sont des endroits où le même jugement s'applique à une surface plus large.

Les parties bougent à des vitesses différentes : un chiffre unique cacherait donc ce dont vous avez besoin. Écrire des points d'entrée est déjà largement du travail de machine. Décider ce qui ne doit jamais arriver quand deux requêtes arrivent ensemble, ou ce qu'un message d'erreur a le droit de révéler, n'a pas bougé, parce que ce sont des positions dont on répond plutôt que de la frappe. Un signal vérifiable : quand quelque chose a cassé le trimestre dernier, le plus dur a-t-il été de le trouver ou de décider quoi en faire.

Sur sa tâche la plus visible, il est moins exposé, et la raison mérite d'être comprise plutôt que prise comme un réconfort : la justesse côté serveur est souvent invisible et coûteuse à rater, donc une plus grande part du travail est de la responsabilité. C'est une différence structurelle, non un classement de difficulté, et cela peut changer — la moitié « points d'entrée » de ce métier est exposée exactement aux mêmes conditions que la moitié frontale.

Pour les entretiens, cela n'a pas changé. Pour le travail, le partage honnête est que se rappeler un algorithme compte moins qu'avant, tandis que raisonner sur la défaillance compte plus — savoir ce qu'une reprise fait à un système déjà en difficulté est la compétence même que les questions de conception cherchent à tester, appliquée à quelque chose de réel. Apprenez-la de vos propres incidents plutôt que d'une liste.

Elle peut déjà en rédiger un, et ce n'est pas la contrainte. La contrainte est que quelqu'un doit garantir ce qu'il ne doit jamais faire, migrer ses données des années plus tard sans rien perdre, et être éveillé quand il tombe. Ce sont des positions de responsabilité, et la responsabilité n'est pas devenue moins chère — dans les domaines réglementés, elle est devenue plus explicitement exigée.