Le regard d'un ingénieur frontend sur le nouveau workflow produit-ingénierie à l'ère de l'IA
Un chiffre qui ne devrait pas avoir de sens
12 jours. Deux personnes : une product designer et un ingénieur frontend. Une reconstruction complète de la plateforme.
Pas un prototype. Pas un MVP. Le remplacement intégral d'une application en production, culminant dans une seule PR qui a supprimé 26 000 lignes de code hérité. Chaque page, chaque route, chaque interaction, reconstruites à partir de zéro et livrées à de vrais utilisateurs.
Dans n'importe quel workflow de développement produit traditionnel, ce calendrier est absurde. Un projet de cette ampleur prendrait généralement des mois : des semaines d'exploration de design dans Figma, des cycles de revue avec les parties prenantes, une cérémonie de handoff, du sprint planning, puis le lent labeur d'une implémentation au pixel près. Ce qui s'est passé ici était fondamentalement différent. Non pas parce que nous avons travaillé plus dur, mais parce que notre façon de travailler ensemble a changé.
Voici l'histoire de la façon dont nous avons livré la plateforme Zero chez VM0, et ce qu'elle m'a appris sur l'avenir de la collaboration produit-ingénierie.
L'ancien goulet d'étranglement
Tout ingénieur frontend connaît le pipeline traditionnel :
- La designer crée des maquettes dans Figma
- Revue de design, itération, validation
- Specs annotées avec espacements, couleurs, breakpoints
- L'ingénieur traduit les specs visuelles en code
- Allers-retours : « Tu peux décaler ça de 4px vers la gauche ? »
- Enfin, on branche la couche API
- Tests d'intégration, encore des allers-retours
Le goulet d'étranglement n'a jamais été dans une étape isolée. Il était dans les interstices entre les étapes : l'attente, la perte à la traduction, le changement de contexte. Le modèle mental qu'une designer se fait d'une interaction, une fois aplati en une frame Figma statique et annoté de lignes rouges, arrive sur le bureau de l'ingénieur déjà dégradé. L'ingénieur reconstruit une version de ce que la designer avait imaginé, mais c'est inévitablement une copie avec perte.
Nous nous étions tellement habitués à ces frictions que nous avions cessé de les voir. C'était juste « comment les choses fonctionnent ».
L'expérience : et si la designer livrait du code ?
Le 5 mars 2026, Ming, notre product designer, a ouvert la PR #3685 : feat(platform): add zero app with shell, pages and polish. Elle ajoutait 4 146 lignes de code React fonctionnel.
Pas un fichier Figma. Pas un export de design tokens. Une application qui tourne.
La PR contenait un app shell complet : navigation latérale, structure de routage, squelettes de pages pour le chat, le planning, l'activité, la gestion d'équipe et les paramètres, le tout stylé avec notre design system, le tout s'affichant dans le navigateur. Les données étaient simulées, mais l'UI était réelle. On pouvait lancer npm run dev et cliquer à travers chaque page.
Ming n'a pas écrit ce code à partir de zéro au sens traditionnel. Elle a utilisé des outils de codage par IA (d'abord Cursor, puis Claude Code) pour traduire directement sa vision de design en composants React. L'IA s'est chargée de la traduction mécanique (structure JSX, propriétés CSS, composition des composants), tandis que Ming dirigeait les décisions visuelles et d'interaction qu'aucune IA ne peut prendre : le rythme de la mise en page, la hiérarchie de l'information, le ressenti des transitions.
Au cours des quatre jours suivants, trois autres PR ont atterri :
| Date | PR | Ce que Ming a livré |
|---|---|---|
| 5 mars | #3685 | App shell, sidebar, tous les squelettes de pages (+4 146 lignes) |
| 6 mars | #3825 | Pages de planning, peaufinage de l'UI (+2 650 lignes) |
| 9 mars | #3993 | Parcours d'onboarding, dialogue de config Slack (+1 146 lignes) |
| 9 mars | #4050 | Page À propos, carte de navigation flottante |
Au 9 mars, toute la surface frontend de notre nouvelle plateforme existait sous forme de code fonctionnel. Chaque page que vous verriez à terme en production était déjà cliquable dans un environnement de dev. Elle ne faisait simplement encore rien de réel.
C'est là que je suis intervenu.
Mon nouveau rôle : insuffler l'âme
Lorsque j'ai ouvert la base de code le 9 mars, je n'étais pas confronté au défi habituel de traduire un design plat en code. Le code était déjà là. Mon travail consistait à remplacer chaque simulation par la réalité, à connecter chaque surface magnifiquement conçue au backend vivant et palpitant en dessous.
Cela a changé mon travail de façon fondamentale. Au lieu de penser en pixels, je pensais en flux de données. Au lieu de demander « est-ce que ça correspond à la maquette ? », je demandais « de quel appel API cette page a-t-elle besoin, et que se passe-t-il quand il échoue ? »
Voici à quoi a ressemblé ma première semaine :
Jour 1 (9 mars) : Authentification et changement d'organisation. J'ai branché le shell de Ming à l'authentification Clerk, ajouté des redirections inter-domaines et fait en sorte que le sélecteur d'organisation change réellement d'organisation. Deux PR, toutes deux mergées le jour même.
Jour 2 (10 mars) : Connecteurs et planning. J'ai remplacé la grille de connecteurs simulée par de vraies données d'API, branché l'onglet planning à de vraies tâches cron et connecté l'éditeur d'instructions au backend. Quatre PR.
Jour 3 (11 mars) : Le grand jour de branchement. La page d'équipe a reçu de vraies données de sous-agents (+3 271 lignes). La page d'activité a reçu de vrais logs. Et le joyau de la couronne : la page de chat a été connectée au véritable pipeline d'exécution d'agents, remplaçant ~1 200 lignes de code de démo par une interface de conversation IA fonctionnelle. Le même jour, j'ai introduit FeatureSwitchKey.Zero, un feature flag qui nous a permis de faire tourner l'ancienne et la nouvelle plateforme côte à côte.
Jours 4-5 (12-13 mars) : Pièces jointes, gestion des sessions, chat multi-agents, persistance des paramètres. Chaque page que Ming avait construite faisait désormais un vrai travail.
Le rythme était presque musical. Chaque matin, je choisissais une page dans le squelette de Ming, j'étudiais sa structure de composants, j'identifiais les données qu'elle attendait, je construisais l'intégration de l'API, je gérais les états d'erreur, et je poussais. À l'après-midi, une autre page était vivante.
Le feature switch : des mondes parallèles
Le feature flag FeatureSwitchKey.Zero mérite sa propre mention, car c'est ce qui a rendu cette migration sûre plutôt qu'imprudente.
À partir du 11 mars, notre application en production faisait tourner deux UI complètes en parallèle. Les utilisateurs de l'ancien système voyaient les anciennes routes. Les testeurs internes du nouveau système voyaient Zero. Chaque page que je branchais pouvait être testée en contexte de production sans risquer le workflow d'un seul utilisateur.
Ce n'est pas révolutionnaire. Les feature flags sont une pratique standard. Mais la combinaison des feature flags avec le workflow design-as-code a créé quelque chose de spécial : nous pouvions valider toute l'UX de la nouvelle plateforme (parce que Ming avait construit une UI complète et navigable) tout en rendant progressivement chaque page fonctionnelle (parce que je les branchais une par une). À tout moment, si quelque chose tournait mal, nous pouvions rebasculer l'interrupteur.
Rien n'a mal tourné.
Jour 12 : le grand basculement
Le 17 mars, j'ai ouvert la PR #5095 : refactor: remove all non-zero platform pages and feature flag.
Le diff : +456 lignes, -26 041 lignes.
Avant : l'ancienne plateforme VM0. Des tableaux, des identifiants de run et des données de session brutes.
Après : le nouveau Zero. Un espace de travail IA conversationnel avec des agents épinglés et des cartes de cas d'usage.
En un seul merge, chaque route héritée a été supprimée. Le feature flag a été retiré. Zero n'était plus une option ; c'était le seul mode. Une PR de suivi (#5155) a complètement abandonné le préfixe d'URL /zero : ce qui était /zero/chat est devenu simplement /chat.
Pourquoi me sentais-je suffisamment confiant pour faire cette coupe ? Parce que :
- Chaque page tournait sous le feature flag depuis au moins 5 jours
- Chaque intégration d'API avait été testée contre des données de production
- L'ancien et le nouveau système partageaient le même backend. C'était un remplacement de frontend, pas une migration de données
- Nous avions de vrais utilisateurs sur le nouveau système qui fournissaient des retours tout du long
Les 26 000 lignes n'ont pas été supprimées avec anxiété. Elles ont été supprimées avec soulagement.
Le schéma se répète
Ce qui m'a le plus surpris, ce n'était pas la migration elle-même. C'était que le workflow que nous avions découvert est devenu notre mode par défaut pour chaque fonctionnalité qui a suivi. Ming construit le shell de l'UI avec l'assistance de l'IA, je branche la logique et j'étends l'architecture. Le même schéma design-as-code, à l'échelle d'une fonctionnalité :
Système de permissions (19 mars → 7 avril)
Ming a livré la PR #5467, une UI de tiroir de permissions avec des composants Sheet et des contrôles à bascule. Trois commits, une UI propre.
J'ai ajouté 13 commits à la même PR : migration de base de données pour firewall_access_requests, endpoints d'API, tests d'intégration, corrections de lint. Puis, au cours des deux semaines suivantes, plus de 10 PR de suivi ont construit toute la couche de permissions : refonte de la carte d'approbation, notifications Slack pour les demandes d'accès, commandes doctor en CLI pour diagnostiquer les problèmes de permissions, et finalement le renommage de tout le concept de « firewall » en « permission » à travers la base de code.
Le tiroir de Ming était la graine. Le système de permissions était l'arbre.
Système de planning (23 mars → 13 avril)
Ming a conçu la route de détail du planning et l'UX de calendrier (#6155). Trois commits de travail d'UI propre.
J'ai ajouté 14 commits : édition de description avec auto-génération, sélection de canal Slack pour les notifications, dialogues de confirmation pour les changements non sauvegardés, unification des vues calendrier/liste, et des tests complets. Puis plus de 15 PR de suivi l'ont étendu en un système complet de tâches récurrentes avec historique des runs, gestion des fuseaux horaires et prise en charge des expressions cron.
Intégration Telegram (27 avril → 28 avril)
À ce stade, le schéma était si bien rodé que nous avons livré une intégration de plateforme entière en 48 heures. Ming a construit l'UI des Settings (#11196) et le parcours d'onboarding (#11399). J'ai construit l'API multi-bots, l'envoi/réception de messages, l'upload/download de fichiers, le contexte de message enrichi, les mises à jour en temps réel via Ably, et les tests E2E. Le lendemain, c'était activé pour tous les utilisateurs.
Où l'IA s'insère
Je tiens à être précis sur le rôle de l'IA ici, car il est facile de le surestimer comme de le sous-estimer.
L'IA a permis à la designer de coder. Ming est product designer, pas ingénieure logiciel. Elle pense en mises en page, hiérarchies et interactions, pas en hooks React et en génériques TypeScript. Les outils d'IA (Cursor, puis Claude Code) ont comblé cet écart en gérant la traduction mécanique de l'intention de design en code fonctionnel. Ming dirigeait ; l'IA tapait. Le résultat était du code rédigé par une designer mais sur lequel un ingénieur pouvait bâtir.
L'IA a accéléré la boucle de revue. Sur les PR collaboratives, mon agent IA passait en revue le code de Ming, classait les problèmes par priorité (P0/P1/P2) et poussait directement des commits de correction. La PR #5060 a traversé cinq cycles de revue en 38 minutes. La PR #5467 a bouclé trois cycles en 20 minutes. Ce n'est pas « l'IA qui remplace la revue de code ». Je lis toujours chaque changement. Mais le travail mécanique d'identification des problèmes de lint, des types manquants et des lacunes de tests a été automatisé.
L'IA n'a pas pris les décisions de design. L'architecture de l'information de chaque page, les patterns d'interaction, la hiérarchie visuelle : tout cela venait de l'instinct produit de Ming, nourri par la recherche utilisateur et l'expertise métier. L'IA peut générer une page de paramètres, mais elle ne peut pas décider de ce qui doit être une bascule plutôt qu'une liste déroulante, ni quand un dialogue de confirmation est justifié plutôt que d'être une friction.
L'IA n'a pas pris les décisions d'architecture. Le choix d'utiliser un feature flag pour un déploiement parallèle, la stratégie de séparation de la couche API, la décision de brancher les pages de façon incrémentale plutôt que toutes d'un coup : c'étaient des jugements d'ingénierie. L'IA m'a aidé à écrire le code plus vite, mais le séquençage et la gestion des risques étaient humains.
Le résumé honnête : l'IA a éliminé la couche de traduction entre design et ingénierie. Elle n'a remplacé aucune des deux disciplines ; elle a supprimé l'écart entre elles.
Ce qui a changé dans mon rôle
Après avoir vécu dans ce workflow pendant trois mois, je vois mon rôle d'ingénieur frontend différemment.
Je ne suis plus un traducteur visuel. L'époque où je recevais un fichier Figma et passais des heures à faire correspondre des valeurs d'espacement est révolue. Non pas parce que je suis plus rapide à le faire, mais parce que ce n'est plus mon travail. L'intention de la designer arrive sous forme de code, pas sous forme d'image du code.
Je suis un extenseur d'architecture. Ma valeur principale est de prendre une surface d'UI fonctionnelle et de construire l'infrastructure invisible en dessous : intégrations d'API, validation des données, gestion des erreurs, vérifications de permissions, mises à jour en temps réel, tests. Le ratio sur la plupart des PR collaboratives raconte l'histoire. Ming contribue 3 commits d'UI, je contribue 13 commits pour tout le reste.
Je suis un gardien de la qualité. Avec des boucles de revue assistées par l'IA, je peux maintenir la qualité du code sur une surface bien plus large qu'auparavant. La revue automatisée détecte les problèmes mécaniques ; je me concentre sur les enjeux d'architecture, les cas limites, et le fait de m'assurer que la fonctionnalité fonctionne réellement de bout en bout.
Je suis un stratège de la livraison. Feature flags, branchement incrémental, déploiements parallèles : le séquençage de la façon dont une fonctionnalité passe du code à la production fait désormais partie intégrante de mon travail, et non d'une réflexion après coup.
Les chiffres
Trois mois. Deux personnes. Assistés par l'IA tout du long.
- 914 PR mergées (679 de moi, 235 de Ming)
- 12 jours du premier squelette au remplacement complet de la plateforme
- 48 heures pour une intégration Telegram complète (notre fonctionnalité la plus rapide)
- 26 000 lignes supprimées en un seul merge confiant
- 88 % de mes PR et 66 % de celles de Ming portent une co-paternité de l'IA
Ce ne sont pas des métriques de hustle. Aucun de nous n'a travaillé le week-end ni passé de nuits blanches. La vélocité vient de l'élimination des temps morts : les réunions de handoff, les incompréhensions de specs, les allers-retours « tu peux décaler ça de 4px ». Lorsque l'intention de design coule directement dans le code, et que l'ingénierie étend ce code sur place, il y a tout simplement moins de gaspillage.
Ce que cela signifie pour les équipes
Je n'affirme pas que toutes les équipes devraient travailler ainsi. Ce workflow a émergé de notre contexte spécifique : une petite équipe, une opportunité de reconstruction greenfield, et un accès anticipé à des outils de codage par IA performants. Les résultats varieront selon les cas.
Mais je crois bien que le glissement sous-jacent est universel : la frontière entre design et ingénierie se dissout, et l'IA est le solvant. À mesure que les outils d'IA s'améliorent dans la traduction de l'intention en code, davantage de designers livreront du code directement. À mesure que cela se produit, les ingénieurs passeront moins de temps sur la traduction et davantage sur l'architecture, la qualité et la livraison.
Le métier d'ingénieur frontend ne disparaît pas. Il change de forme. Et honnêtement ? La nouvelle forme est plus intéressante.
Yuma est ingénieur frontend chez VM0, où il construit la plateforme qui propulse Zero, un système d'exploitation pour agents IA. Il a supprimé en masse plus de code hérité qu'il ne voudrait l'admettre.
