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 !