Trois scènes, même semaine

Mardi. Standup. Un développeur frontend mentionne qu’il a terminé la feature. Toute la feature. Le endpoint API, la migration, le composant React. Il avait demandé à la machine de l’aider sur la partie Rails. Un senior back a reviewé mercredi matin. Deux commentaires mineurs. Merged.

Personne n’a sourcillé.

Il y a trois mois, ce ticket aurait été découpé en trois. Un ticket back, un ticket front, un meeting de synchro pour s’assurer que les contrats d’API matchent. Deux personnes, trois jours, un standup de plus. Pour le même résultat.

La frontière n’a pas été abolie par décret. Elle s’est estompée par la pratique. Des fronts qui font du back, des backs qui touchent du React, avec un expert qui passe derrière à la fin du projet. Un filet humain tendu sous les acrobaties de l’IA.

Pendant le projet, personne n’attend. Ça va plus vite.

J’ai toujours résisté à la spécialisation. Chez nous, on parle de product engineers. On a quelques spécialistes front, quelques mobiles, du back. Mais la majorité de l’équipe est fullstack.

React, on en met sur les pages vraiment riches, celles où l’interactivité justifie la complexité. Le reste, c’est du bon vieux server-side rendering. ERB, Rails, du HTML qui arrive tout cuit du serveur. Même sur mobile, on fait pas mal de backend-driven UI. Le serveur décide quoi afficher, le client rend.

C’est un choix. Moins de spécialisation, moins de dépendances entre les gens, moins de coordination. Un·e product engineer prend un problème de bout en bout. Comprend le domaine. Parle aux stakeholders. Ship.

Ça marchait déjà avant les LLM. Mais la machine a changé le truc. Un backend qui écrit du React avec du state compliqué. Un mobile qui écrit son propre endpoint. Un frontend qui fait la migration et le modèle. Pas parce qu’ils ont appris, parce que la machine comble les trous. Et pour l’instant, ça tient. La review attrape ce qui doit être attrapé. Le code part en prod. Les utilisateur·ices ne voient pas la différence.

En 2005, ça s’appelait un webmaster. Une personne. Le HTML, le PHP, le MySQL, et le FTP le vendredi soir.

On a spécialisé. Front, back, DBA, ops, mobile. Parce que les stacks sont devenues trop profondes pour un seul cerveau.

Alors on a inventé les squads. Cross-fonctionnelles. Des spécialistes regroupés par domaine produit. L’unité autonome de livraison. Le rêve de Spotify.¹

La squad, à l’origine, c’était deux choses en une. Un regroupement technique (ingés, PM, data, designers dans la même pièce) et un ancrage métier (supply, demand, pricing…).

Si la machine efface le regroupement technique, si n’importe qui peut toucher n’importe quelle couche, il reste l’ancrage métier. Et peut-être que c’est ça qui comptait depuis le début.

Le dev supply connaît les hôtes, leurs parcours, leurs frustrations. Le dev demand connaît chaque étape du funnel de réservation. Ce qui les rend bons, c’est pas qu’ils maîtrisent React ou Rails, c’est qu’ils ont passé des mois à comprendre un problème. Parce que même avec les meilleures specs du monde, un dev prend dix micro-décisions produit par jour. Et celles-là, personne ne les écrit.

Alors la tentation c’est de dire : collons le dev directement à côté de l’expert métier et laissons-les ship en binôme. Plus de proxy. Plus de tickets qui traversent trois colonnes Jira. Juste deux personnes et la machine entre les deux.

Mais.

Les stakeholders connaissent leurs problèmes. Ça ne veut pas dire qu’ils savent les résoudre. Pas quand ils ne sont pas tech native. J’ai vu des briefs qui demandaient une page de configuration avec quarante champs alors que le vrai besoin c’était un toggle.

On a inventé les métiers de PM et de designer précisément pour ça, pour traduire un besoin en solution, pour protéger l’utilisateur de la vision du commanditaire.

Et les devs ? Pas tous doués non plus pour proposer des solutions sobres. L’overengineering, c’est un réflexe de métier. Construire le système extensible plutôt que la chose qui marche. J’ai écrit du code inutilement flexible pendant des années. (J’en écris probablement encore.)

Le binôme dev-expert métier, c’est séduisant sur le papier. En pratique, il manque toujours quelqu’un pour dire non, pas comme ça, plus simple. Parfois c’est un bon dev. Parfois c’est un bon stakeholder. Parfois c’est quelqu’un dont c’est le métier, PM, designer, peu importe l’étiquette. C’est rarement la machine.

Mercredi. LinkedIn. Un Product Manager poste une vidéo. Il a construit un outil interne seul. Cursor, trois jours, du prototype au déploiement. I shipped this without writing a single line of code myself. Trois cents likes.

Les commentaires : moitié enthousiasme, moitié silence. Le silence des développeur·euses qui scrollent, qui voient, et qui ne savent pas trop quoi en faire.

Si le PM ship, si le designer code, si la frontière entre qui décide et qui implémente n’existe plus…

Les rôles se dégonflent. PM, dev, designer, des étiquettes qui décrivaient des compétences exclusives, et qui décrivent de moins en moins.

Et si le code n’est plus le monopole des développeur·euses, qu’est-ce qui l’est ? La compréhension des systèmes ? Le debugging à 3h du matin quand le PM-qui-ship est couché ? La capacité à dire “non, ce code passe les tests mais il va casser dans six mois quand on changera le schéma” ?

LinkedIn passe son temps à le dire : tout le monde est développeur·euse maintenant. J’ai du mal à y croire. Un POC qui tourne sur la machine du PM, c’est une chose. Un produit qui tient debout avec des vrais utilisateur·ices, des investisseurs, une boîte qui fait cent millions, c’est autre chose.

L’expertise, la vraie, celle qui sait ce qui va casser à l’échelle, j’ai encore du mal à imaginer qu’on s’en passe.

Mais les LLM évoluent vite. Et j’ai déjà eu tort sur ce genre de choses. 🙃

Vendredi. Un senior de l’équipe passe la journée à reviewer des PRs. Du code écrit par la machine, poussé par des gens qui connaissent le domaine mieux que la stack. Il attrape un race condition que personne n’avait vu. Corrige un problème de sécurité. Vire une abstraction inutile.

À 18h, pas une ligne écrite. Et pourtant.

Je me demande si c’est pas ça, le métier, en fait. Pas écrire du code. L’attraper avant qu’il casse. Savoir ce qui va merder dans six mois parce qu’on a déjà vu merder le même truc trois fois. Le genre de savoir qui ne s’automatise pas (pas encore) parce qu’il vient des cicatrices, pas des patterns.

Trois scènes. Même semaine. Je ne sais pas ce qu’elles racontent ensemble. Pas encore.

Le front fait du back. Le PM ship. Le senior ne code plus. La squad tient debout mais plus pour les mêmes raisons. Les étiquettes se décollent.

On a inventé le full-stack plusieurs fois. La prochaine, peut-être que ce n’est plus du full-stack. C’est un truc qui n’a pas encore de nom.

(En attendant, je continue à appeler mon équipe des product engineers. Ça tiendra bien encore un peu. 🙃)