90 % de votre processus de conception d'agents est obsolète

AAI LABS
Computing/SoftwareSmall Business/StartupsManagementInternet Technology

Transcript

00:00:00L'ancien processus de création comportait une étape qui n'existe plus aujourd'hui.
00:00:03La plupart des équipes n'ont pas encore trouvé par quoi la remplacer, alors elles continuent
00:00:06d'utiliser l'ancienne méthode par pure habitude.
00:00:08Cette semaine, Jenny Wen a publié une interview dans le podcast de Lenny.
00:00:11Elle est responsable du design pour Claude chez Anthropic, et avant cela, directrice du design
00:00:16chez Figma.
00:00:17Dans cet épisode, elle explique que le processus de design classique est mort et ce qui le remplace
00:00:21concrètement.
00:00:22Nous allons donc analyser ce qui a changé, pourquoi, puis passer en revue le processus exact
00:00:26qui l'a remplacé.
00:00:27Pour comprendre ce remplacement, il faut d'abord comprendre pourquoi l'ancien système existait.
00:00:31Auparavant, on définissait d'abord les besoins, puis un designer créait sur Figma
00:00:35une maquette du rendu final de l'application.
00:00:38Ce fichier Figma servait de document de transmission entre l'idée et la réalisation.
00:00:43Un développeur front-end convertissait ensuite ce fichier en code.
00:00:46Pendant ce temps, le développeur back-end travaillait en parallèle, car les spécifications API
00:00:51étaient définies dès le départ pour que tout s'assemble à la fin.
00:00:55Jenny décrit cela comme un processus que les designers suivaient de manière rituelle.
00:00:58C'était la norme dans toute l'industrie.
00:01:00Pourtant, beaucoup oublient la raison fondamentale pour laquelle ce système existait.
00:01:05Simon Willison, un développeur très influent dans le milieu technique,
00:01:09a résumé la conférence de Jenny à Berlin en y ajoutant une analyse cruciale
00:01:14qu'elle sous-entendait sans le dire explicitement.
00:01:16Développer avec l'IA réduit considérablement le coût d'une erreur de conception.
00:01:19Avant l'IA, une mauvaise direction signifiait des mois de travail perdus pour les ingénieurs.
00:01:23Une petite erreur de front-end multipliait par dix la charge de travail lors de l'implémentation.
00:01:27Les équipes justifiaient donc chaque étape.
00:01:28Recherches, personas, parcours utilisateurs, wireframes, cahiers des charges...
00:01:33Tout servait de protection contre une erreur de construction à grande échelle.
00:01:36Alors, qu'est-ce qui a vraiment changé dans le processus ?
00:01:38C'est d'abord la vitesse de développement qui a évolué.
00:01:40Et elle a changé plus vite que ce que la plupart des gens ont réalisé.
00:01:42Jenny raconte qu'il y a quelques années, elle passait 60 à 70 % de son temps à maquetter.
00:01:48Aujourd'hui, c'est seulement 30 à 40 %.
00:01:49Ce n'est pas elle qui a décidé de changer sa façon de travailler.
00:01:51Les ingénieurs autour d'elle ont commencé à utiliser plusieurs agents en parallèle,
00:01:55et soudain, le goulot d'étranglement n'était plus le développement.
00:01:58Le développement a muté en premier, et le design a été forcé de suivre.
00:02:00Les délais de vision ont également changé.
00:02:02Le design produisait autrefois des visions à 2 ou 5 ans.
00:02:04Désormais, la technologie évolue si vite qu'une portée de 3 à 6 mois est plus réaliste.
00:02:09Et ce n'est plus forcément une présentation Powerpoint.
00:02:11C'est un prototype qui montre la direction à suivre.
00:02:13La même chose est arrivée à l'étape de traduction du design.
00:02:15Quand un agent peut prendre un document de besoins et créer une interface fonctionnelle,
00:02:19la couche de transition disparaît.
00:02:20L'agent écrit directement le code.
00:02:22Il n'y a plus de fichier Figma à traduire car il n'y a plus besoin de fichier Figma.
00:02:25Au passage, si vous aimez notre contenu, n'hésitez pas à cliquer sur le bouton "hype"
00:02:29pour nous aider à produire plus de vidéos de ce genre et à toucher plus de monde.
00:02:33Pour nos projets clients, c'est précisément ce virage que nous avons dû prendre.
00:02:36Le processus de design a changé, mais ce qui reste crucial, ce sont les exigences.
00:02:40De mauvaises exigences gâchent tout le travail de construction.
00:02:42Et la plupart des équipes passent directement aux spécifications techniques.
00:02:44C'est une erreur.
00:02:45Pour un prototype, pas besoin de stack technique ou de spécifications API.
00:02:48Vous devez en savoir juste assez pour bâtir quelque chose qui ressemble au produit réel,
00:02:52pour pouvoir le présenter et obtenir une validation ou un refus.
00:02:56Avant de toucher au prototype, commencez donc par définir les acteurs.
00:02:58Un acteur est une personne qui interagit avec le système.
00:03:01Une personne précise avec un objectif précis.
00:03:03L'utilisateur détermine ce que le système doit faire.
00:03:06Si vous avez quelqu'un qui soumet du contenu et un autre qui l'approuve,
00:03:10ce sont deux interfaces différentes avec deux écrans d'accueil distincts.
00:03:12Ensuite, regardez où les vues se séparent.
00:03:13Dans la plupart des produits, deux acteurs différents accèdent à la même URL
00:03:18mais voient des choses totalement différentes.
00:03:19L'administrateur voit un panneau de gestion.
00:03:21L'utilisateur lambda voit son tableau de bord.
00:03:22Enfin, il y a les contraintes.
00:03:24Ne dites pas à l'agent quels outils utiliser.
00:03:26Dites-lui ce qu'il ne peut pas faire et ce que cela ne doit pas coûter.
00:03:28Cela facilitera grandement les décisions techniques plus tard.
00:03:32Nous avons intégré toutes ces règles dans un prompt de création de PRD (cahier des charges),
00:03:37qui vous interroge selon ces principes
00:03:42en vous posant une série de questions ciblées.
00:03:44À la fin, vous obtenez un fichier PRD au format Markdown,
00:03:48qui servira de base pour la suite du processus.
00:03:49Ce fichier PRD est le socle de tout le reste.
00:03:52L'étape suivante consiste à le transformer en structure pour le front-end.
00:03:55Pour cela, nous utilisons un prompt qui demande à l'agent d'analyser le PRD,
00:04:00qui n'est pas encore un document technique complet, pour produire deux éléments.
00:04:04Il doit lister les pages et les fenêtres modales du prototype,
00:04:08ainsi que les flux d'utilisateurs.
00:04:09La structure des pages et des modales est essentielle pour que tout ce que l'agent
00:04:14doit coder en front-end soit planifié à l'avance.
00:04:17Nous répétons souvent que la planification est primordiale avant l'action,
00:04:21surtout pour l'IA et sa fenêtre de contexte, donc pas besoin d'insister.
00:04:24Mais pour les flux, il est crucial de définir les actions de chaque acteur.
00:04:28Comme nous nous concentrons sur les acteurs et non les fonctionnalités,
00:04:32ces flux permettent à l'agent d'implémenter les bons états d'interaction
00:04:36et la navigation adéquate pour le prototype complet.
00:04:40On finit avec deux fichiers dont architecture.md qui contient les pages, les modales
00:04:45et les flux d'utilisateurs mentionnés.
00:04:46Après cela, nous lui avons demandé d'installer une application Next.js,
00:04:50car c'est la stack que nous utilisons habituellement avec Supabase.
00:04:53Et voici ce qu'il a généré.
00:04:55Dans l'ensemble, le design est superbe, et il y a une raison précise à cela.
00:04:58Petit détail oublié : le projet était une plateforme communautaire avec des canaux,
00:05:03des produits et des cours.
00:05:04Il y a deux acteurs : le membre et le créateur.
00:05:08Le créateur a les fonctions d'admin comme créer un canal, ajouter un produit
00:05:12ou charger un cours, tout en consultant ses statistiques.
00:05:15Pour un premier prototype, nous trouvons le design vraiment réussi.
00:05:19Toutefois, l'expérience utilisateur (UX) n'est pas encore optimale.
00:05:23Mais c'est justement là tout l'intérêt.
00:05:24Ce genre de correction prenait des jours, ici cela prend quelques minutes.
00:05:27L'IA peut effectuer ces modifications extrêmement rapidement.
00:05:30Et comme il n'y a pas encore de back-end, il n'y a pas de complexité supplémentaire,
00:05:34c'est juste un prototype front-end.
00:05:36D'habitude, l'IA ne produit pas d'interfaces aussi esthétiques.
00:05:40Si le résultat est bon ici, c'est grâce à une compétence front-end polyvalente
00:05:44qu'Anthropic a partagée sur l'un de ses blogs.
00:05:46Nous recommandons vivement d'utiliser cette méthode avant de générer votre UI.
00:05:50Enregistrez-la comme une commande ou une compétence pour que votre agent l'utilise.
00:05:53Si vous travaillez pour un client, il suffit de lui montrer ce prototype,
00:05:57qui est totalement fonctionnel avec des données fictives,
00:06:01puisqu'il n'y a pas encore de base de données réelle.
00:06:02Vous le présentez au client, obtenez son accord, ou faites les modifs,
00:06:06puis vous passez à la suite du développement.
00:06:08Ces listes de tâches sont l'une des raisons pour lesquelles nous pouvons
00:06:12maintenant demander aux agents de créer des prototypes complets.
00:06:14C'est grâce à ces listes, à la persistance des tâches et à une structure claire.
00:06:17Tout est organisé.
00:06:18C'est pourquoi ce fichier architecture.md était si important : il permet à
00:06:23l'agent de créer une liste de tâches optimisée pour éviter toute hallucination.
00:06:28On passe ensuite à l'implémentation du back-end.
00:06:30En général, deux options s'offrent à vous.
00:06:32Vous pouvez garder Next.js pour le front-end et implémenter le
00:06:36back-end via un service Python séparé.
00:06:39Mais cela dépend du type d'application sur laquelle vous travaillez.
00:06:42Pour la plupart de vos projets, Next.js suffira amplement.
00:06:46Un back-end Python est nécessaire si vous avez besoin de bibliothèques spécifiques
00:06:50indisponibles sous Next.js, ou d'une orchestration complexe de tâches de fond
00:06:55pour optimiser les fonctions de votre site.
00:06:57Dans ce cas précis, un back-end séparé se justifie.
00:06:59Sinon, le back-end intégré à Next.js fera parfaitement l'affaire.
00:07:03Avant d'attaquer le back-end, il faut savoir ce que le front-end attend de lui.
00:07:07Nous avons demandé à l'agent d'analyser le code front-end, le PRD et l'architecture
00:07:11pour rédiger une spécification API.
00:07:12Puis, il a utilisé ces documents pour créer le schéma Supabase complet
00:07:17puisque nous utilisons le duo Supabase + Next.js.
00:07:20Il s'agit de créer les schémas qui vont héberger les données de l'application.
00:07:25Normalement, un agent classique vous dirait de récupérer vos clés API,
00:07:28d'aller sur la base de données et de coller manuellement des requêtes SQL.
00:07:33À la place, vous devriez utiliser le MCP de Supabase.
00:07:36Privilégiez toujours un MCP pour le service sur lequel vous travaillez car cela automatise
00:07:40énormément de choses.
00:07:41Par exemple, nous n'avons même pas eu besoin de regarder le projet.
00:07:43Il a créé le projet, lancé les requêtes de schéma et effectué les
00:07:48migrations automatiquement.
00:07:49On n'a quasiment rien eu à faire.
00:07:51Une fois la base de données prête, vous connectez le front-end à celle-ci.
00:07:55Encore une fois, il y a une distinction claire ici.
00:07:57Pas besoin de connecter le back-end à la base, car c'est déjà intégré
00:08:00au front-end.
00:08:01Le front-end communique directement avec la base, ce qui simplifie l'intégration
00:08:06et réduit la complexité globale.
00:08:07Pour cette vidéo, nous sommes partenaires de Warp qui a récemment lancé OZ,
00:08:11une plateforme d'orchestration pour différents agents cloud.
00:08:14Ces agents sont très pratiques pour déléguer des tâches que
00:08:19l'IA peut gérer en toute autonomie.
00:08:21Jusqu'ici, l'agent avait relié le front-end à la base de données et l'appli
00:08:26fonctionnait déjà sur cette base.
00:08:27Mais pour ajouter le paiement, des notifications, des limites de débit ou des analyses
00:08:32sur le site, il nous faut une couche API back-end dédiée.
00:08:37On a donc créé un environnement via OZ et lancé un agent cloud pour
00:08:41construire cette couche back-end spécifique.
00:08:43Environ 15 minutes plus tard, la tâche était terminée et tout était prêt.
00:08:47Pour rendre le tout opérationnel et accueillir des utilisateurs, il ne restait plus
00:08:51que l'authentification Google, Stripe et quelques finitions.
00:08:56Vous avez maintenant vu tout le processus et les prompts affichés à l'écran.
00:09:00Si vous voulez retrouver tous ces prompts sous forme de workflow pas à pas
00:09:04pour vos propres projets, nous les avons mis dans AI Labs Pro.
00:09:06C'est notre communauté où vous trouverez des modèles prêts à l'emploi
00:09:10pour cette vidéo et toutes les précédentes.
00:09:14Si vous appréciez notre travail et voulez soutenir la chaîne, c'est le meilleur
00:09:18moyen de le faire.
00:09:19Le lien est dans la description.
00:09:20C'est la fin de cette vidéo.
00:09:22Pour nous soutenir et nous aider à continuer ce genre de contenu,
00:09:26vous pouvez utiliser le bouton "Super Thanks" ci-dessous.
00:09:28Merci de nous avoir suivis, et à la prochaine !

Key Takeaway

Le processus de design traditionnel est remplacé par un cycle rapide où l'IA transforme directement des exigences centrées sur l'utilisateur en prototypes fonctionnels, éliminant ainsi le besoin de maquettes statiques et de transmissions manuelles.

Highlights

Le coût des erreurs de conception a chuté radicalement grâce à l'IA, rendant les processus de validation rigides obsolètes.

La part de temps consacrée au maquettage par les designers est passée de 70 % à environ 30 % avec l'avènement des agents de développement.

La disparition du fichier Figma comme document de transmission, car les agents peuvent coder directement à partir des besoins.

L'importance cruciale de définir les "acteurs" (utilisateurs spécifiques) et leurs flux plutôt que de simples fonctionnalités.

L'utilisation de protocoles comme le MCP (Model Context Protocol) pour automatiser la gestion des bases de données comme Supabase.

Une nouvelle hiérarchie documentaire : du PRD (cahier des charges) à l'architecture.md pour guider l'IA sans hallucinations.

Le passage d'une vision produit à 5 ans à des cycles de prototypes fonctionnels de 3 à 6 mois.

Timeline

La mort du processus de design traditionnel

L'ancien modèle reposait sur une séparation stricte entre le design sur Figma et le développement front-end et back-end. Jenny Wen, responsable chez Anthropic, explique que ce système servait de protection contre les erreurs de construction coûteuses avant l'ère de l'IA. Aujourd'hui, l'IA réduit massivement le coût d'une erreur de conception, rendant les recherches de personas et les wireframes systématiques moins nécessaires. Simon Willison souligne que ces étapes étaient des rituels de justification désormais dépassés par la vitesse d'exécution technologique. Ce changement de paradigme force les équipes à repenser la valeur ajoutée du designer dans le flux de production.

L'évolution des rôles et des délais

Le temps de travail des designers est redistribué, le maquettage ne représentant plus que 30 à 40 % de leur activité contre 70 % auparavant. Ce changement est poussé par les ingénieurs qui utilisent des agents IA en parallèle, déplaçant le goulot d'étranglement du développement vers la conception. Les visions stratégiques à long terme sont remplacées par des portées plus réalistes de 3 à 6 mois basées sur des prototypes concrets. Le fichier Figma disparaît en tant que couche de transition car l'agent IA peut générer l'interface directement à partir des documents de besoins. Cette section met en avant la fin de la traduction manuelle du design vers le code informatique.

Définir les besoins : Acteurs, Vues et Contraintes

Pour réussir un prototype avec l'IA, il est impératif de se concentrer sur les exigences plutôt que sur la technique pure. La méthode recommandée consiste à définir précisément les acteurs, c'est-à-dire les personnes réelles ayant des objectifs spécifiques au sein du système. Il faut ensuite identifier où les interfaces se séparent selon les rôles, comme la distinction entre un panneau d'administration et un tableau de bord utilisateur. Les contraintes doivent porter sur ce que l'agent ne peut pas faire ou sur les limites de coûts, plutôt que sur les outils à utiliser. Le résultat final de cette étape est un fichier PRD en Markdown qui sert de socle structuré pour l'IA.

De l'architecture au prototype front-end

Le PRD est transformé en un document d'architecture détaillant les pages, les modales et les flux d'utilisateurs. Cette planification est essentielle pour éviter les hallucinations de l'IA et respecter sa fenêtre de contexte limitée lors de la génération. L'utilisation d'une pile technologique comme Next.js permet de générer rapidement des interfaces esthétiques, surtout en utilisant des compétences de design partagées par Anthropic. Le prototype obtenu est fonctionnel avec des données fictives, ce qui permet de le présenter immédiatement au client pour validation. Cette approche permet de corriger l'expérience utilisateur en quelques minutes au lieu de plusieurs jours dans l'ancien système.

Implémentation du back-end et automatisation

Le passage au back-end commence par l'analyse du code front-end pour générer une spécification API et un schéma de base de données. L'intervenant recommande l'usage de Supabase couplé à Next.js, en insistant sur l'utilisation du protocole MCP pour automatiser la création des tables et les migrations SQL. Cette automatisation évite les manipulations manuelles fastidieuses et les erreurs de configuration entre le front-end et le stockage des données. Le front-end communique alors directement avec la base de données, simplifiant l'architecture globale pour la majorité des projets web. Un back-end Python séparé n'est suggéré que pour des besoins très spécifiques comme l'orchestration complexe ou des bibliothèques absentes de l'écosystème JavaScript.

Finalisation et orchestration avec des agents cloud

Pour les fonctionnalités avancées comme les paiements Stripe ou les notifications, une couche API dédiée est construite via des plateformes d'orchestration comme OZ de Warp. Des agents cloud autonomes gèrent ces tâches en arrière-plan, permettant de livrer un produit complet et prêt pour les utilisateurs finaux en un temps record. La vidéo conclut sur l'importance d'adopter ces nouveaux flux de travail et ces listes de tâches structurées pour maximiser l'efficacité de l'IA. Les prompts et méthodes présentés sont disponibles pour la communauté afin de faciliter cette transition vers le design d'agents moderne. L'appel final encourage le soutien de la chaîne pour continuer à produire des analyses sur l'évolution du développement assisté par IA.

Community Posts

View all posts