Un audit que j'ai mené sur le front-end de mon propre produit a trouvé quatre listes éditables qui suivaient leurs éléments par position, sur des tableaux modifiés en place. Ça compilait, et rien dans le build ne se plaignait. Supprimer un élément au milieu de la liste poussait le framework à réutiliser le nœud DOM de l'élément supprimé pour l'élément suivant, si bien que la saisie et l'état de focus propres à chaque élément pouvaient s'attacher au mauvais élément jusqu'à un re-rendu complet. Une revue centrée sur le style approuverait ce diff. J'ai corrigé les quatre et ajouté un spec qui fige ce comportement. Repérer ce genre de bug est maintenant une plus grande partie du travail.
Netguru écrit qu'en 2026, le travail front-end senior ressemble moins à écrire des composants qu'à diriger un système qui les écrit. La première partie correspond à ce que je vois : produire un composant n'est plus là où se trouve la valeur. Je décrirais le reste autrement. Diriger, ça sonne comme de la gestion, alors que le travail ressemble plutôt à lire, décider et rendre la mauvaise chose difficile à faire.
Je construis mon propre produit, MailHive, avec Angular 21 et un workflow assisté par IA, et jusqu'en août j'étais le seul développeur front-end d'une équipe de cinq développeurs chez BMO. Dans les deux cas, le composant n'a jamais été la partie difficile. L'IA a juste enlevé le paravent que fournissait le fait de le taper.
Lisez le comportement, parce que le style n'est plus une preuve
Le code généré a l'air propre. De bons noms, une structure soignée, des commentaires aux bons endroits. Avant, c'étaient de faibles signaux que l'auteur avait bien réfléchi. Aujourd'hui, ce sont des preuves bien plus faibles encore. Il faut lire ce que fait le code quand l'état change.
Qu'une personne ou un modèle les ait tapées ne change rien pour le reviewer. Le piège est le même dans les deux frameworks avec lesquels je travaille :
<!-- Angular. Position is not identity when the list mutates. -->
@for (condition of conditions; track $index) { ... }
<!-- Follows the object while its reference is stable. Prefer condition.id if you have one. -->
@for (condition of conditions; track condition) { ... }{/* React. Same trap. */}
{rows.map((row, i) => <Row key={i} {...row} />)}
{/* Follows the item. */}
{rows.map(row => <Row key={row.id} {...row} />)}Un concept comme celui-ci se transpose entre Angular et React. Une liste de noms d'outils, non.
Prenez en charge les états que personne n'a demandés
Demandez un écran et vous obtenez l'écran. Vous obtenez le chemin nominal, bien rendu. Le travail du senior, c'est la liste que le prompt n'a pas mentionnée : le compte vide, le réseau lent, l'enregistrement qui échoue avec la moitié du formulaire modifiée, la permission révoquée en cours de session, le lecteur d'écran, le libellé français bien plus long que l'anglais. Si vous avez déjà travaillé de Figma jusqu'à la production, vous savez que cette liste est l'essentiel du vrai travail.
Mon parcours en UX aide ici. Ces états sont une décision produit avant d'être du code. Que doit voir l'utilisateur quand ça échoue, et peut-il s'en remettre ? Un modèle inventera volontiers une réponse. Quelqu'un doit d'abord remarquer que c'était une décision, et la porter à la personne qui en est responsable.
Transformez votre goût en contraintes
Relire deux fois la même erreur est le signe que la vérification devrait être automatisée. La première fois que vous la voyez, demandez-vous si une machine peut l'attraper à partir de là. Voici une partie de ce qui vit maintenant dans le dépôt de MailHive, plusieurs éléments venant d'un audit du dépôt et pas d'un seul bug :
- Des règles de lint qui imposent les frontières de modules, pour qu'un nouvel import d'une feature vers une autre échoue, avec les violations existantes mises en baseline.
- Des règles d'accessibilité sur chacun de nos templates, avec les violations existantes mises en baseline pour que seules les nouvelles échouent.
- Une vérification que les quatre fichiers de langue contiennent les mêmes clés, pour qu'une clé de traduction manquante fasse échouer le pipeline et pas l'utilisateur.
- Des instructions de projet que l'IA lit, plus un registre des bugs passés qu'elle ne doit pas répéter, où chaque entrée doit faire référence à un vrai incident.
- Des registres de décision qui expliquent pourquoi un choix d'architecture a été fait, pour que personne, ni moi ni un modèle, ne le rouvre par accident.
Chacun rend les mille prochaines lignes générées un peu plus sûres. La recherche DORA de Google qualifie l'IA d'amplificateur des forces et des faiblesses existantes d'une organisation. À l'échelle d'un seul dépôt, ce sont les contraintes qui sont amplifiées, ou leur absence.
Dites non tôt, parce que le code est trop facile à ajouter
Quand ajouter du code ne coûte presque rien, la tentation est d'en ajouter. Chaque abstraction, helper et service généré devra quand même être lu, testé et migré par quelqu'un plus tard. Supprimer du code et refuser d'en générer, les deux comptent comme du travail. MailHive a un job CI, knip, qui échoue sur le code front-end inutilisé, parce que le volume à lui seul finira par enterrer un petit produit.
Même chose pour les grosses réécritures. Un modèle en planifiera et en rédigera une volontiers, et il ne sera pas là pour expliquer la régression au client. Quelqu'un doit peser le risque par rapport à ce que l'entreprise y gagne, et dire tout haut quand la réponse est non.
Gardez la compétence qui vous permet de juger
C'est pour ça que le mot diriger ne décrit pas le travail, pour moi. Vous ne pouvez juger un constat comme ces quatre listes que parce que vous comprenez comment un framework réconcilie une liste. On juge du code généré avec des connaissances qui viennent du fait d'écrire et de déboguer du code. Si vous arrêtez de construire ces connaissances, vos revues s'affaiblissent, lentement, et rien ne vous prévient.
Je n'ai pas de réponse nette à ce risque, surtout pour les gens en début de carrière. Le Digital Economy Lab de Stanford constate que l'emploi des 22 à 25 ans dans les métiers très exposés est environ 19 % en dessous de ce qu'il serait s'il avait suivi le rythme de leurs pairs moins exposés, sans écart comparable pour les travailleurs expérimentés. Les auteurs le présentent comme descriptif, pas causal. Ça m'inquiète quand même, parce que c'est des juniors d'aujourd'hui que viendront les prochains seniors. Ce que j'essaie de faire moi-même : aller en profondeur, exprès, dans les domaines dont je suis responsable. Écrire moi-même la partie difficile quand j'ai besoin de la comprendre. Traiter une explication de l'IA comme une hypothèse de départ, puis lire la documentation du framework et le test qui échoue.
Ce qu'il faut montrer en entrevue
Un billet du blog de Stack Overflow d'octobre 2026 donne aux employeurs une phrase qui mérite d'être retenue : embauchez pour le jugement, pas pour une liste d'outils. La maîtrise des outils compte, mais c'est la partie la plus facile à montrer, et la plupart des candidats mentionnent maintenant Copilot ou Claude Code. Voici plutôt les histoires que je préparerais, avec un exemple réel pour chacune :
- Une fois où vous avez repéré quelque chose qui avait l'air correct et qui était faux. Qu'est-ce qui l'a trahi ?
- Un garde-fou que vous avez ajouté après une erreur, et ce qu'il a attrapé depuis.
- Un état ou un parcours que personne n'avait spécifié, et comment vous avez fait en sorte que la décision soit prise.
- Quelque chose que vous avez décidé de ne pas construire, et ce que ça a permis d'épargner.
- Comment vous décidez quelle sortie de l'IA mérite une lecture attentive et laquelle mérite une lecture rapide.
Chacun de ces points est une histoire de jugement, et le jugement est ce que le rôle demande maintenant.
Références
- Netguru. Is frontend development dying? https://www.netguru.com/blog/is-frontend-development-dying
- Stack Overflow Blog. Is AI really reshaping the developer market? October 2026. https://stackoverflow.blog/2026/10/22/is-ai-really-reshaping-the-developer-market/
- Brynjolfsson, Chandar, Chen. Canaries in the Coal Mine, Stanford Digital Economy Lab. https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/
- DORA. 2025 State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/
- Angular. Track expressions in @for blocks. https://angular.dev/guide/templates/control-flow
- React. Why React needs keys. https://react.dev/learn/rendering-lists
- knip. https://knip.dev/