Dev Mode : revisitez votre workflow de développement avec vos équipes design

0:00 Mundo On a les premiers participants qui nous rejoignent. Merci. On va attendre encore quelques minutes.

3:50 Bordeaux, Paris, Ajaccio, on est dans toute la France. Je ne sais pas combien de personnes sont arrivées en fait. Pour l'instant, on a une dizaine de personnes connectées. Et effectivement, Jaxio, c'est chouette, c'est assez... C'est tout qui vient. Il pleut beaucoup aujourd'hui. J'allais le dire. J'espère que tu es un peu plus beau à Jaxio qu'à Caparil. Peut-être que c'est pareil, on ne sait pas. Jean Guillemot. Merci, Pamela. Ok, 12h05, je vous propose de commencer.

4:52 Bonjour à toutes, bonjour à tous. Moi, c'est Florence Chabanoy. Aujourd'hui, j'ai le plaisir d'accueillir Emmanuel. Je ne sais pas si vous connaissez Emmanuel. Cabane, il est solution architecte chez Figma. Il a fait ses armes dans des grands groupes comme Dell, Oracle, et aussi des scale-up comme Airbnb et Criteo. Avant de démarrer, je vais laisser la parole à Noémie Cogé, notre chère présidente de Tech.Rocks, qui va vous parler de quelque chose de très important. Merci beaucoup Florence, alors j'espère que vous m'entendez bien. Alors ravie d'être avec vous, je suis un gros plan. Ravie d'être avec vous ce midi. L'idée c'était de faire une rapide introduction, donc on a fait ces masterclass suite à vos deux mondes, on vous a entendu. Voilà l'année dernière on avait pas mal de deux mondes, de trois, de quatre, avec un peu de psychologie, justement il pouvait y avoir cette interaction et puis cet échange vraiment privilégié. C'est pour ça qu'on a lancé plusieurs masterclass qui sont notamment menées par Alexandre qui anime le chat actuellement donc n'hésitez pas, on a d'autres masterclass qui arrivent et l'idée c'est vraiment que ce soit un format par et pour vous donc n'hésitez pas à créer aussi

6:02 le côté interactif au travers des questions directement, vous avez un onglet, vous pouvez poser vos questions et puis Florence et Emmanuel seront à votre disposition aussi pour y répondre l'idée c'est en effet donc on a ces masterclass et puis c'est pour justement c'est comme une introduction finalement à notre Tech.Rocks Summit qui est notre grand événement de l'année 2 et 3 décembre prochain on parle de résilience, d'écosystème en mouvement c'est pas une résilience subie mais c'est bien On s'adapte, on optimise et on innove. Voilà, donc on a deux jours de conférences qui vont être vraiment très chouettes. On a été à Paris cette année, on est ravis, on a plein de surprises sur place. Donc, on sera ravis de vous y retrouver. Moi, je me ferai un plaisir aussi de vous accueillir si vous venez et d'échanger avec vous. Et je vais redonner la parole à Florence, qui est une membre phare de la communauté Tech.Rocks, et qu'on remercie d'avoir accepté d'animer cette masterclass. Et évidemment à Emmanuel, qui va nous présenter justement un peu plus Figma au travers de cette masterclass.

7:03 Voilà, merci beaucoup à tout le monde. Pardon, je découvre l'outil. Merci Nelly. Alors Figma, c'est quand même beaucoup plus connu dans le monde des designers. Et aujourd'hui, Emmanuel va nous parler plus de la partie pour les devs, donc le dev mode. Je te passe la main. Emmanuel. Je te remercie Florence. A mon tour du coup, bonjour à tous, bonjour à toutes. Je suis ravi d'être avec vous pour ces 45-50 prochaines minutes. J'espère que vous allez bien, qu'il pleuve ou pas. Je m'appelle Emmanuel Cabane. Je suis architecte solution à Figma et aujourd'hui, si vous le voulez bien, je vous emmène pour une petite plongée, une découverte à la croisée des mondes entre le design et le développement. Alors, côté résilience, qui est effectivement le thème de Tech.Rocks cette année, comme l'a dit Noémie, c'est quelque chose que j'ai vécu au jour le jour. Ces deux dernières années à Figma, avec les clients que j'ai eu la chance d'accompagner, principalement parce que les sujets dont je vais vous parler aujourd'hui sont des sujets relativement nouveaux, qui prennent souvent du temps, particulièrement pour les grandes structures, mais pas que.

8:19 Parce que ces équipes qui créent des produits, elles se heurtent avec la conduite du changement. Et c'est pour ça qu'on trouvait ça assez logique d'orienter vraiment ça sur le côté de la résilience. Alors, vous le verrez dans mon introduction, Figma a beaucoup changé ces deux dernières années. Et mon rôle, logiquement, aussi. Solutions Architect, ça veut dire quoi? Vous êtes sûrement familier avec ça, mais mon équipe est responsable du succès technique de nos clients. J'ai eu la chance d'accompagner des groupes de toute taille, que ce soit des catelons de ce monde, des scale-up comme par exemple Conto, qui sont à nos clients aussi. jusqu'aux petites PME, qui sont peut-être aussi les futurs fleurons de la tech française, qui sait? Alors, pour l'agenda, il va être très simple aujourd'hui. Je vais juste vous présenter qu'est-ce que c'est Figma. Sûrement, vous êtes familier avec qu'est-ce qu'on fait, mais exactement, mais Quid de DevMode, qui est aussi dans le titre de la présentation aujourd'hui. Et avant de rentrer vraiment dans le vif du sujet, ce qui vous intéresse sûrement un peu plus, avec une démo live où je pourrais prendre des questions en direct, je vais essayer de regarder, garder un oeil sur le chat qui sera sur ma droite,

9:29 et à la fin on va dédier toute une section avec Florence, plus sur une section questions-réponses, de telle façon à pouvoir répondre à vos questions. Alors, comme je le disais un peu plus tôt, sans prendre trop de risques, si vous êtes ici, c'est que vous connaissez sûrement Figma. Mais si j'avais à parier, je pense que vous connaissez notre plateforme principalement sur notre outil de design et de prototyping. Et c'est effectivement quelque chose, c'est comme ça qu'on s'est fait connaître. Mais notre produit a beaucoup évolué. pour maintenant couvrir l'ensemble du processus du développement de produits. L'idée en tête était simple, c'est qu'on cherchait à ce que les différentes équipes qui collaborent dans tout un cycle de création de produits collaborent, mais essayent de résoudre leurs problèmes. Dans un espace partagé. Et si vous avez déjà été dans un fichier Figma, ce que j'espère, et vous ne serez sûrement pas surpris, souvent de tomber sur une collègue dans le même fichier qui se balade avec son curseur.

10:33 Et utilisant notre propre produit interne, on s'est rapidement, nous Figma, on s'est rendu compte que nos outils réunissaient bien plus que le persona pour qui on avait construit Figma à la base, donc les designers, mais réunissait aussi des personnes côté produit, des UX researchers, des PO, des devs, des TL, etc. Sauf que, petit hic, notre plateforme a été conçue avec les designers en tête. Et un simple exemple, Tout le comportement basique de Figma, c'est de pouvoir zoomer, dézoomer sur des composants, des fichiers. Et les développeurs qui travaillent principalement sur les outils d'édition de code, un IDE, on n'est pas en zoom in, zoom out, effectivement. Et on s'est bien rendu compte qu'on n'avait pas forcément des produits qui parlaient à cette audience de développeurs. Sauf que, encore une fois, petit x, c'est qu'un tiers des personnes sur Figma s'identifient comme développeurs. ou ingénieur. Alors, comme vous le voyez sur la frise, Figma, ça a quand même bien grandi.

11:36 Ces deux dernières années, on est passé d'un produit core, qui est quand même Figma Design, donc c'est vraiment l'outil de prototyping, et de UI UX, qui a été créé à 8 ans de ça. Mais ces deux, trois dernières années, on s'est vraiment développé dans une myriade de produits qui couvrent la plupart du cycle de développement d'un produit, de la découverte, de la conceptualisation, du cadrage. On passe bien sûr par la conception, donc la création du design par les équipes design, jusqu'au passage de relais entre les équipes de design et de développement. Et si vous êtes là aujourd'hui, c'est sûrement que c'est la dernière étape qui vous intéresse. Et ça tombe bien, c'est sur ce quoi on va se concentrer aujourd'hui. Alors? Tout simplement pourquoi? Parce qu'on peut se demander, mais Figma, votre cœur de métier, c'est un outil design. Mais on s'est bien rendu compte qu'à quoi bon créer des fichiers Figma qui sont parfaits, si une fois que c'est mis en main dans la main d'un ou d'une dev, si ces fichiers sont incompréhensibles, s'ils ne sont pas navigables?

12:39 Ça sert à quoi? Et après tout, c'est ce que Figma est à la base. Ce qu'on est à l'heure actuelle, c'est permettre une sorte d'abstraction visuelle et de ce que vous devez créer en production, de ce que vous devez donner vie, que ce soit, je ne sais pas moi, un user flow, une application, une interface web, Ce que nous, on s'est posé comme question, c'est comment nous, on peut aider vous, côté dev, à mieux utiliser les fichiers Figma, à mieux les naviguer, les parcourir, pour faciliter ce travail de traduction de cette abstraction à la réalité en code dans les applications mobiles ou web que vous faites. Et quand on a commencé à s'aventurer un peu dans le monde des développeurs, il y a à peu près deux ans de ça, c'est ce dont on s'est rendu compte. C'était plutôt un consensus, c'est que tout le monde veut réussir à créer des designs de qualité et les pousser en production rapidement. Mais c'est facile à dire et c'est beaucoup plus difficile à faire.

13:43 Et on s'est demandé le pourquoi, le pourquoi du comment, qu'est-ce qui s'est passé, pourquoi est-ce si difficile de non seulement avoir de la qualité mais aussi de la rapidité. Et grâce à cette recherche, on a mis en avant trois points, trois obstacles principaux à laquelle les équipes qui sont impliquées dans ce cycle de développement de produits, à laquelle elles se heurtent. Le premier problème, c'est le fait de travailler en silo. Vous êtes sûrement familier avec ça. Le tech stack, même chez nous à Figma, on a tellement d'outils que ça devient difficile. Que ce soit trouver la documentation dans un Google Doc, dans un Notion, dans un Paper, aller dans mon Azure DevOps ou dans mon Jira pour essayer de trouver un peu plus de suivi de mon projet. on se retrouve avec une communication qui est hachée et avec un faible alignement. Dans un deuxième temps, c'est vraiment l'adoption du design system, que ce soit vraiment dans les prémices d'un design system, que ce soit d'un simple UI kit ou quelque chose qui a été défini en code,

14:48 C'est quelque chose qui, par exemple, peut être difficile à trouver parce qu'on peut se retrouver à devoir recréer un composant alors que ce composant existe quelque part ailleurs. Qui mène inexorablement de fil en fil. en aiguille à une expérience utilisateur qui n'est pas forcément folle et une qualité de produit qui baisse. Et le troisième problème à laquelle les équipes de développement et de design se heurtent, c'est Cette inefficacité côté dev, mais aussi qui crée une sorte de frustration côté design entre le changement de contexte constant qui se passe, par exemple, entre je suis un dev, je dois chercher ma documentation dans mon zero height ou dans mon intranet interne, ou je vais essayer de retrouver, mettons, je bouge dans mon IDE, je dois copier du code à gauche à droite, pour un peu je me trompe d'onglet, etc. Et ça force un peu, ça érode ce flow et de pouvoir garder. Vous ou vos équipes de développement dans le flow.

15:51 Et l'impact sur le business qu'on a pu mettre en avant, il est clair. C'est-à-dire, on se retrouve avec des potentiels bugs, des retards sur les deadlines, des régressions potentielles, le pire cauchemar. Ou, de l'autre côté, on peut se retrouver avec une qualité de produit qui est faible, une vraie différence entre ce qui avait été imaginé côté design et la réalité en code. d'avoir quelque chose qui est moins cohérent ou parfois on se doit de recréer des choses qui existent déjà. Et dans un troisième temps, ça c'est plus sur un thème systémique, c'est on continue à creuser le fossé entre les équipes d'ISRA. On sait très bien que ce sont deux populations de personnes complètement différentes qui parlent une langue différente, mais on essaie d'avoir un peu cet overlap entre les deux. Et c'est avec ça en tête, c'est avec ces trois soucis qu'on a créé DevMod. Alors vous le voyez ici sur la slide, pourquoi j'ai mis entre parenthèses nouvelle, c'est que DevMod a presque deux ans maintenant. Mais si vous devez penser à DevMode en une seule phrase, c'est un espace dédié aux développeurs au sein de Figma.

16:57 Le but, il est simple. On a créé ce produit pour éviter les allers-retours entre designer et développeur. Quand un dev commence son sprint et doit commencer à travailler, transformer, traduire cette abstraction visuelle en code, mais aussi faciliter la prise de contexte, faciliter la compréhension des différents fichiers, le tout en s'intégrant aux différents stacks que vous pouvez avoir. Je vais l'aborder un peu plus tard, mais on a aussi des partenaires technologiques qui nous permettent de se connecter avec Jira, etc. Le but est simple, tout ce que j'ai mis en avant un peu plus tôt, c'est-à-dire minimiser les bugs, éviter les régressions et pousser en production plus rapidement et de façon plus confiante, c'est-à-dire plus safe aussi. Et ça peut paraître un peu contradictoire, mais le but qu'on essaie d'avoir à Figma, c'est que vous, côté dev, que nous au final, c'est qu'un dev ou qu'une dev passe moins de temps dans Figma. Et le but, c'est vraiment que cette personne, une fois qu'elle consomme,

18:00 ce fichier Figma, qu'elle puisse en extraire tout ce dont elle a besoin, que ce soit le contexte, que savoir qu'est-ce qui a changé le avant-après, dans le minimum de temps possible. Et si c'est quelque chose qu'on arrive à faire avec DevMode, on est déjà ravis. DevMode, au final, on a pu mettre en avant trois différents piliers qui vont ressembler aux trois thématiques qu'on a mis en avant un peu plus tôt. Les trois piliers sur lesquels on essaie vraiment de pouvoir améliorer ce workflow d'efficacité au niveau du développement de produits côté Dev. Le premier pilier, c'est aligner les différentes organisations. On se rend bien compte qu'avec toutes les différentes populations et toutes les différentes personnes impliquées dans un cycle de développement de produits, on se retrouve avec, certes, j'avais mentionné les designers et les devs, mais on reste sur le stéréotype, mais si on se retrouve avec un PO, un TL, un US Researcher, on se retrouve avec pas mal de personnes. Et si tout le monde se rejoignait au sein d'un seul produit? Et c'est pour ça que l'alignement des organisations, c'est vraiment sur avoir tout le monde dans le même produit, mais aussi avoir le contexte plus rapidement, ajouter des annotations, pouvoir s'assurer que

19:11 tout soit mis en avant et mis en surface rapidement. Et dans un troisième temps, se connecter au stack que vos développeurs ou que vous-même utilisez, de telle façon à ce que vous n'avez pas forcément à chercher et à faire ce changement de contexte que je mettais en avant un peu plus tôt. Et c'est aussi pour ça que... C'est pour ça que nous avons un partenariat avec les grands de ce monde, donc là c'est juste pour en citer quelques, soit Chromatic côté Storybook, Atlassian côté Jira, GitHub, etc. Pour s'assurer que peu importe où vous travaillez, on essaie de vous rencontrer à mi-chemin, de telle façon à ce que quand vous vous connectez à un fichier Figma, vous voyez tout le contexte dont vous avez besoin et vous n'avez pas à ouvrir. X onglets, X étant le nombre d'outils que vous utilisez. Dans un deuxième temps, DevMod essaie vraiment d'améliorer la qualité du produit. C'est-à-dire favoriser l'adoption des design systems. Certes, on peut partir de zéro et essayer de créer du code automatique, ou si votre design system est déjà défini en code, pourquoi pas le mettre en surface et le mettre en avant quand vous cliquez sur des composants dans un fichier Figma.

20:24 Donc, que ce soit des exemples de code, l'intérêt, c'est vraiment de pouvoir non seulement adopter le design system d'un point de vue développeur, mais aussi s'assurer qu'il soit utilisé et bien consommé côté design. Dans le but, évidemment, d'éviter le duplicata, éviter de réinventer la roue, etc. Dans un troisième temps aussi, c'est pouvoir s'assurer d'une source de vérité commune. Donc là, c'est un simple exemple, mais par exemple, ça va être sur l'utilisation de notre API qui est dédiée aux variables, donc à nos design tokens, de telle façon à ce que si vous souhaitez... Faire en sorte que votre code repos, ce soit la source de vérité, vous puissiez utiliser notre API pour changer et modifier les fichiers Figma qui maintenant feront foi. Et dans un troisième temps, c'est vraiment l'efficacité côté dev, c'est-à-dire optimiser les workflows des développeurs pour non seulement qu'ils comprennent le côté, ce qu'on peut appeler diffing, c'est-à-dire le avant-après, donc comparer les différents changements,

21:32 mais aussi vous rencontrez côté dev là où vous évoluez déjà. Par exemple, vous utilisez un IDE comme Visual Studio Code, VS Code, maintenant ce que nous on peut proposer c'est essayer d'afficher un fichier Figma au sein de votre Visual Studio Code. De même, dans un troisième temps, c'est un exemple parmi tant d'autres, et on va rentrer dans la démo juste après, c'est-à-dire la visualisation des composants. Comment ce composant se comporte en fonction des différents états? Si vous avez un Storybook, ça peut être aussi ajouté en complément, mais ce qu'ils appellent dans Storybook, c'est les stories, c'est-à-dire ce bouton, quand je le survole, à quoi ressemble-t-il? Quand il est désactivé, comment change-t-il? etc. Donc, au final, pour faire très simple, DevMod, c'est ce qu'on avait en tête à la base, c'est-à-dire augmenter l'efficacité des développeurs, s'assurer que les organisations et les différents départements, différentes personnes impliquées dans un cycle de dev de produit, elles soient toutes alignées, ou qu'on évite ce type de friction et cette érosion, mais aussi dans un troisième temps,

22:41 augmenter la qualité du produit et s'assurer que les 10 systèmes, s'ils sont déjà créés, soient adoptés. C'est tout pour les slides. J'ai promis d'être relativement succinct là-dessus avant de rentrer dans le vif du sujet. Et on va passer directement dans la démo. Alexandre, je te laisse le soin de mettre... Je te remercie, t'es encore plus rapide. Alors, je vous avais dit que je vous amène à la croisée des chemins entre le design et le développement. J'espère ne pas vous avoir menti. Là, je vais faire semblant d'être un designer. Ici, mon travail en tant que designer est terminé, ou presque.

23:42 Parce qu'effectivement, ce qui est important, et ce que j'essaie vraiment de mettre en avant, c'est que... La qualité de ce passage de relais, de handoff comme ils disent en anglais, ce passage de relais, la qualité dépend entièrement de ce que vos équipes design vous donnent en main. C'est pour ça que je mets vraiment en avant cette responsabilité partagée. Et c'est aussi pour ça que j'en reviens un peu à cet esprit de résilience et de conduite de changement, parce que c'est quelque chose qu'on a en tête et on peut toujours se dire en tête que les designers et les développeurs sont deux personas complètement différents, mais si les deux doivent travailler et collaborer ensemble, c'est quelque chose qu'on peut aussi mettre au centre et au centre des attentions. Et moi, en tant que designer sur ce type de fichier, c'est relativement facile de me retrouver parce que c'est moi qui l'ai designé, c'est moi qui ai un peu écrit ça à gauche à droite. Mais si aujourd'hui vous arrivez en tant que dev et que vous arrivez sur un fichier comme ça, Bon courage.

24:48 Pourquoi? Parce que si moi, en tant que dev, j'arrive là-dessus, je vois qu'il y a eu des itérations, je vois qu'il y a des post-its, je vois qu'il y a des contextes, je vois qu'il y a quelques sketchs qui ont été... effet rapidement, je ne sais pas où donner de la tête. Je vois qu'il y a des notes avec des dates qui ont été mises ici et là. Peut-être qu'il y a un prototype qui a été mis là. Mais c'est difficile pour moi de savoir par quoi commencer. Et c'est là où encore je mets vraiment la responsabilité sur le côté design dans ce cas-là, c'est la qualité du handoff commence par le côté design. Et c'est quelque chose qui, vous en tant que dev, vous avez le droit d'exiger. C'est quelque chose qui, pour moi, est extrêmement important en tant que dev, de demander à l'équipe design, de me donner le bon contexte et d'avoir les bonnes informations pour que je fasse mon taf correctement. En tant que designer, comment je commence mon handoff? Ce que vous pouvez faire, c'est commencer à sélectionner une frame ou une section, une sélection de frame, la flaguer ou la marquer comme prête à être développée en Ready for Dev.

25:54 Quand je clique sur cette frame, vous allez voir une toute petite icône ici, sur laquelle je peux cliquer, et qui me permet de marquer toute cette section avec une petite icône maintenant en vert, qui permet de dire au côté développement que... Cette section est prête à être développée. Ce que moi je peux faire en tant que designer maintenant, c'est juste cliquer là-dessus et copier le lien. C'est un lien que je copie et que je peux partager directement à mon ou ma dev et ajouter, mettons, dans mon Azure DevOps, dans mon Jira, etc. J'enlève ma casquette de designer. Ici, si je prends ma casquette de développeur, Je récupère ça dans mon gira. En entrant directement ce lien, je vais tomber sur ce qu'on appelle une vue focus. Cette focus view est relativement simple, c'est-à-dire comment moi je peux me concentrer sur ce qui est pertinent. En comparaison à ce qu'on voyait un peu plus tôt, ici, Vous voyez ici, moyen de se perdre, il y a des centaines de layers sur la gauche, je ne sais pas où de l'aide la tête.

26:55 Ici, il n'y a pas plus simple. Je vois un seul design, et ce qui est important, c'est, vous voyez en bas à droite, les différentes versions qu'il y a. C'est-à-dire, je vois ici, donc là vous pouvez voir qu'il y a une heure, je travaillais sur ce fichier, et on peut savoir l'horodatage, donc le timestamp, qui a changé, et quels ont été les changements qui ont été opérés. Ici, en tant que développeur, ce que je peux faire directement, c'est survoler, avoir un peu d'expérience de ce qui se passe dans ce fichier, mais essayer de comprendre rapidement. Par exemple, ici, quand je clique là, il est facile pour moi de comprendre que non seulement je vois qu'il y a des spacings qui ont été ajoutés, des variables ici et là, mais je comprends directement, notamment avec le box model sur la droite, qu'est-ce que ces composants sont censés faire. Donc là, par exemple, je vois qu'est-ce qui est censé être cliqué, qu'est-ce qui est censé être ajouté, etc. Alors ça, je l'ai aussi expliqué dans les slides un peu plus tôt, mais je vais vous donner...

28:01 Un scénario qui arrive bien plus souvent qu'on aimerait, qui est, Je suis dev, je commence mon sprint, et depuis que ce design a été ajouté, il a peut-être changé. Quand quelque chose change au milieu de mon sprint, un vrai cauchemar dans le sens où, à quoi je suis censé, qu'est-ce qui est censé faire foi? Est-ce que je suis censé commencer à travailler sur la version qui a été marquée ou la nouvelle version? Pourquoi ça a été changé? Et c'est des questions que nos clients se posent régulièrement et qu'on voulait mettre en avant. Je vais enlever ma casquette de développeur et reprendre ma casquette de designer. Pourquoi? Parce que maintenant, je me rends compte qu'effectivement, j'ai eu un petit meeting avec l'équipe marketing, bien que j'ai touché à ce design il y a deux, trois semaines, et on m'a fait... On m'a fait part que le mot basket devrait être traduit plutôt en carte à la place. Sauf que vous le voyez ici, il a déjà été mis en prêt à être développé, en ready for dev.

29:05 Donc ici, malheureusement, je vais devoir changer ça. Et j'ai changé même l'icône qui est plus sur la droite, juste ici. Et maintenant, ce n'est plus add to basket, mais add to cart. Sauf que ce que vous pouvez voir maintenant, c'est que maintenant, quand je survole ici, on a pu mettre en avant que le design a été changé depuis la dernière fois qu'il était marqué et flagué en tant que Ready for Dev. Quand je clique dessus, je vais pouvoir donner une explication de qu'est-ce qui s'est passé. Donc, je vais pouvoir expliquer que, mettons, l'équipe copywriting a expliqué que le basket a changé à carte. Donc maintenant, j'enlève ma casquette designer, j'ai fait mes changements de dernière minute, désolé monsieur ou madame la dev, je change côté développeur, et quand j'arrive dans Figma côté développeur, donc en dev mode, On peut juste y accéder en appuyant sur le bouton en bas à droite, ici, ou avec le raccourci Shift majuscule D.

30:09 Là, ce qu'on peut voir, c'est exactement la même chose qu'on peut voir sur un fichier Figma, à la simple différence que je ne peux rien modifier. C'est-à-dire que c'est le but qu'on a en tête. Un designer peut changer le fichier, une dev ou un dev ne devrait pas pouvoir changer le fichier. Logiquement, on est là pour consommer le fichier, en extraire tout ce dont j'ai besoin pour le pousser en production et le transformer en code. Par rapport au scénario que je mettais un peu en avant un peu plus tôt, sur la partie Ready for Dev, que vous pouvez voir en haut à gauche, maintenant je vois que mon alter ego, Emmanuel Cabane, a ajouté une nouvelle version du design, il y a une minute. Donc non seulement j'ai le redatage, mais en plus de ça je vois exactement ce qui a changé. Donc certes, je peux mettre en avant ce qui a changé depuis la dernière fois, mais ici, je vais pouvoir voir que le changement du copywriting est passé de basket à carte. En zoomant, maintenant je peux comprendre exactement ce qui s'est passé. Quand je vous parlais de l'outil de diffing, c'est-à-dire de l'aspect un peu avant-après, maintenant c'est quelque chose qu'on peut voir directement.

31:16 Non seulement on a un historique des versions, mais aussi je peux comparer exactement ce qui a changé. Ici, par rapport à la version d'il y a 5 minutes, ici d'un simple coup d'œil, je peux rapidement voir que c'est Add to Basket, Add to Cart, et en cliquant sur toutes les différentes... 40 layers qui ont changé, je suis directement zoomé sur ce qui est important et je vois que non seulement j'ai changé l'alignement, donc je suis passé de center à center and mean, mais qu'en plus de ça, j'ai changé le mot basket à carte. Donc si vous avez en tête de... Faire des designs et les transformer en code en pixel perfect, c'est vraiment quelque chose qui est important à utiliser sur le côté avant-après. Bien sûr, on propose des choses en overlay pour essayer de comprendre ce qui s'est passé avant-après. Mais par exemple, là c'est un exemple sommaire et relativement grossier, mais si demain cette couleur noire devient du gris très foncé, c'est quelque chose qu'on va pouvoir voir, mettons ici, vous voyez une variable qui a été mise en avant. Au lieu que ce soit du 000, donc le code décimal du noir, on va pouvoir voir les changements exacts.

32:24 Donc quelque chose qui peut éventuellement être raté à l'œil nu, maintenant est mis en avant de façon très claire dans le code. Quelque chose qui peut être aussi très important pour moi, c'est par exemple en tant que développeur, essayer de comprendre comment un bouton réagit. Dans mon cas ici, quand je clique sur ce bouton qui est maintenant Add to Cart, je vais pouvoir voir toutes les propriétés que mon ou ma designer a mis en place. Je vois le contexte qui a été mis et je vois que la documentation a été liée à un lien Storybook. Si je clique dessus, je vais être redirigé sur... mon lien chromatique Storybook, et pouvoir jouer avec ça. Par contre, je peux aussi, c'est aussi dans mon droit, essayer de comprendre, plutôt qu'avoir plusieurs captures d'écran, avoir un fichier Figma pour comprendre comment ce composant évolue en fonction des différents états. Et pour ça, on a mis en avant ce qu'on appelle un component playground, donc une façon safe d'expérimenter avec un composant pour voir les différents états et comment ce composant se comporte.

33:30 Quand je clique sur le component Playground, je vais pouvoir voir plusieurs choses. Je vais pouvoir voir toutes les différentes propriétés qui ont été mises en place par le côté design. C'est aussi là où c'est important d'avoir une équipe design qui sait bien utiliser Figma et qui le documente bien. Par exemple, ici, je vois que c'est mon bouton secondary, mais en primary, je comprends qu'il n'est pas en noir sur blanc, mais en blanc sur noir. Et notamment, l'état, est-ce que je veux le passer en survol? Est-ce que quand je clique dessus, à quoi ressemble-t-il? Ok, je vois qu'il passe en vert, etc. Et de même, si je veux... Et afficher une icône, c'est quelque chose que je peux faire, ou choisir la banque d'icônes en fonction de ce dont j'ai besoin, et swapper l'instance pour, par exemple, un panier rempli au lieu d'un panier vide. Chose que vous avez peut-être aussi remarqué, c'est... Le petit encart en violet en bas à droite. Ça, je vais le mettre en avant un peu plus tard, mais c'est dans un monde qui s'appelle Code. C'est au sein de Figma aussi, au sein de DevMode.

34:33 C'est quelque chose qui, par exemple, si vous avez un design system déjà défini sous forme de code, donc mettons, j'ai mon code défini dans mon site internet en interne, en React, en Angular, en Vue, peu importe. Si c'est quelque chose qui est déjà défini, Et s'il y avait un monde où quand je clique sur un composant, je pouvais le mettre en avant, donc ici dans mon cas, directement, je sais que c'est mon code propriétaire à moi, et je sais que tout ça, c'est le code que je... doit utiliser. C'est quelque chose que je vais mettre un peu plus en avant plus tard, mais c'est quelque chose qui est aussi possible. Dans un dernier temps aussi, et c'est là où j'essaie d'expliquer, c'est que tout ça, ça reste quand même une vue d'un fichier Figma, vraiment orienté développeur, certes, mais si j'ai besoin d'avoir un peu plus de contexte au sein de ce composant. Et si je dois, par exemple, lier... Ce design de bouton, ce passage en production, cette transformation en code, et la lier, mettons, avec un Epic Jira, une User Story, etc.

35:40 Et c'est là où tout notre écosystème d'intégration rentre en jeu. Et vous pouvez le voir si vous avez des yeux assez aiguisés, vous pouvez le voir un peu en haut à droite. On a un petit écosystème de partenaires qui travaillent avec nous, donc Atlassian, GitHub, parmi tant d'autres. Et là, dans mon cas, je peux très bien sélectionner le plugin de Jira, donc de chez Atlassian, qui me permet ici, par exemple, d'ajouter une ressource dev, Voilà, je vous avais dit, les démos live qui vous permettent d'ajouter, mettons, une ressource dev. Donc, je vais aller, mettons, directement dans mon Atlassian. Et admettons, ajouter par exemple cette carte en particulier, la copier, et si j'ai besoin de l'ajouter au sein d'une ressource dev qui est liée exactement à ce composant, c'est quelque chose que je peux coller directement ici. Et ici, quand je clique dessus, je peux voir exactement la carte Jira qui, moi, va m'être intéressée, avec la personne

36:52 à qui a assigné la tâche d'Angira, mais aussi... Qui l'a reporté avec la liste des différents commentaires. Donc au final, c'est quelque chose qui est assez complet. Ou quand je vous parlais d'éviter les différentes frictions, éviter les régressions, éviter les bugs, c'est quelque chose qu'on essaie vraiment de résoudre et de tacler le plus possible. Quelque chose que vous avez peut-être pu voir et directement quand je suis rentré dans le DevMode, ce sont ces petites bulles qu'on appelle des annotations. Ces notations, mettons, ça va être mis en place par le côté design. Ici, je vois directement et ça me permet d'avoir le contexte dont j'ai besoin. Par exemple ici, je sais que mon carousel devrait avoir un maximum de 8 items et que ça devrait avoir un effet de bounce quand je change d'une image à l'autre. Et donc ça me permet exactement moi de comprendre en tant que développeur de ne pas avoir à aller directement dans mon Teams, dans mon Slack ou peu importe quel outil de communication j'utilise en interne pour aller demander à...

38:04 À mon ou ma designer du contexte sur quelque chose qu'elle a touché ou qu'il a touché il y a trois semaines, où elle a peut-être un peu pu perdre le contexte. Et si cette personne avait déjà tout mis au lieu d'ajouter des petits post-it comme ce qu'on pouvait voir un peu plus tôt ici, ça c'est flou, ça c'est beaucoup plus parlant. En revenant dans le fil d'actualité qui est vraiment dédié, c'est l'espace vraiment dédié pour les développeurs. Par exemple, ici, si je prends cet exemple d'application, Il y a tout un pan qu'on a pu mettre en avant qui est orienté sur comment rencontrer les développeurs là où ils travaillent. Donc, dans un cas où, admettons que vous utilisez Visual Studio Code, c'est quelque chose qu'on peut travailler. Donc ici... C'est un peu caché, mais ça va être en haut à droite. C'est quelque chose que vous pouvez démarrer depuis Figma ou au sein de votre VS Code. Ça passe par une extension VS Code, l'extension en...

39:06 entièrement gratuite, vous pouvez aller dans votre Visual Studio Code. Si vous utilisez un fork de VS Code, par exemple Cursor, c'est quelque chose qui fonctionne aussi. Vous pouvez l'installer depuis VS Code, sur le Marketplace qui est dédié à VS Code, et chercher Figma, Figma for VS Code, vous le retrouverez. Ou vous pouvez, depuis un fichier Figma, dans DevMode, cliquer en haut à droite et ouvrir cette frame en particulier sur... VS Code. Et ici, je vais me retrouver avec la même expérience, mis à part que j'ai un thème dark dans mon VS Code, donc tout est en noir sur blanc. Et ici, je vais avoir le même feed que vous pouvez voir un peu plus tôt, ou si je peux basculer sur tous les designs qui sont prêts à être développés, je peux très bien revenir sur la même vue. Ce fichier est live, donc encore une fois, je ne peux pas le modifier, mais vous voyez que c'est, encore une fois, c'est du multiplayer, donc je vois mon... qui est à l'heure actuelle dans ce même fichier. Et toute l'expérience que j'ai pu avoir un peu plus tôt est exactement la même.

40:09 Donc si je reviens sur ce sur quoi j'étais un peu plus tôt, je vais pouvoir retrouver exactement ce qui m'intéressait. Donc la même chose, les propriétés, le différent code qui a été fait automatiquement, Si je reviens à la dev ressource que j'ai pu mettre en avant, ici tout ce qui a été lié par mon côté design ou même côté dev, je vais pouvoir le retrouver. Que ce soit si je sais que ce bouton a déjà été codé et qu'il est présent dans mon code repo, lui ajouter un lien GitHub ou faire en sorte que ce soit lié à mon storybook, etc. Les liens peuvent très bien être custom, si vous avez un design system qui est défini en interne, qui n'est pas forcément une de nos intégrations, c'est quelque chose qui peut être ajouté ici en tant que ressource dédiée aux développeurs. Emmanuel? Tu m'entends? En parlant de design system et comme tu parles de la partie code, on a une question de Rémi dans le cadre d'un composant partagé. Comment gérer le nommage des classes CSS et le respect des conventions de nommage entre les différentes équipes qui vont l'utiliser?

41:15 C'est une très bonne question. Par exemple, ce qu'on peut utiliser aussi, par exemple, au sein de Figma, ça va être des variables. On peut avoir une syntaxe de code qui est utilisée. de façon différente. Par exemple, une variable qui est définie dans Figma par le côté design peut ne pas répondre d'un point de vue nomenclature à ce qui est attendu côté dev. Mais c'est quelque chose qu'on peut utiliser si le côté design sait quelle syntaxe utiliser côté code. C'est une question de la gouvernance. C'est vraiment le côté dev qui dit, est-ce que tu peux t'assurer que cette classe apparaisse de telle façon? C'est quelque chose qui peut être fait dans un fichier Figma. Après, sur le code qui est mis en avant, c'est peut-être un peu plus difficile, dans le sens où on a deux façons de mettre du code en avant dans Figma. Là, je vais juste vous reprendre un exemple. Ici, par exemple, j'ai deux possibilités.

42:18 Donc, on va rentrer dans un monde où on va prendre les deux choix. Le premier choix, c'est je n'ai pas de design system et je dois coder ce composant pour la première fois. Dans ce cas-là, je peux très bien cliquer sur un composant. On va prendre celui-là, c'est peut-être plus simple. On va prendre le header, c'est parfait. Et ici, je peux utiliser, mettons, un des plugins qui mettent en utilisation du code autogénéré. Donc, par exemple, ici, on a une liste de plugins que je vous laisse le soin de découvrir. Mais par exemple, ici, FileMap2Code, si par exemple, j'ai besoin de ce code en Tailwind ou en React ou en Flutter, peu importe, c'est quelque chose que je peux mettre en avant si ça veut bien fonctionner. De le mettre ici. L'autre monde, c'est si ce code est déjà créé, et c'est ce monde-là en haut à droite, c'est-à-dire code connect. C'est-à-dire ici, ça demande une maturité un peu plus avancée, c'est-à-dire Au niveau des prérequis, ça demande que ce soit maintenu côté développeur et ça demande aussi que le design system soit défini en code.

43:30 Donc là, il y a moins le besoin de gouvernance pour demander au côté design, est-ce que tu peux t'assurer que cette nomenclature soit respectée? Là, c'est plutôt si je clique sur ce bouton, Je veux afficher ce code-là. Ça se passe par... par la CLI, donc Command Line Interface. C'est quelque chose qui se passe par... On utilise NPM à l'heure actuelle. Ça s'appelle Code Connect. C'est un lien que Adrien, d'ailleurs, dans le chat, vous partagera sûrement. Et c'est quelque chose qui supporte de mettre en surface du code qui vous appartient, donc avec la nomenclature et la syntaxe que vous souhaitez, quand vous cliquez sur peu importe quel composant dans Figma. Et dans ce cas-là, nous, on supporte à l'heure actuelle Vue, React, Angular, et aussi des frameworks web, donc Web Components et plus mobile, donc du coup SwiftUI et Compose. J'espère que ça répond à la question. Et je vais rebasculer sur mon VS Code.

44:36 Merci. Pas de souci. Et du coup, ce que je voulais vraiment mettre en avant sur VS Code, j'étais presque arrivé à la fin, donc c'est une très belle transition, Florence, je te remercie, qui est au final, pourquoi on essaie de s'intégrer dans VS Code, c'est qu'on s'est bien rendu compte rapidement que VS Code a des... Si VS Code est connu, est très utilisé, c'est aussi pour de bonnes raisons. Et ça a des capacités d'auto-completion. Si en plus on rajoute à ça le côté IA avec cursor et d'autres, les capacités sont assez infinies. Sauf que ce qu'on avait en tête par exemple, c'est quand je commence à travailler sur un code en particulier, donc ici je vais prendre l'exemple que j'avais en tête, je vais utiliser les deux exemples que je mettais en avant par rapport à la question qui a été posée. Je vais ouvrir un nouveau fichier, je vais sélectionner mon langage, on va utiliser du CSS. Et ici, par exemple, je sais que je suis sur ce bouton qui s'appelle tout simplement, de façon très sobre, bouton.

45:38 Mais ici, ce que je vais pouvoir, mettons, directement avoir, c'est une sélection de, par exemple, si je sélectionne ce bouton en particulier, voilà. Quand je commence ma classe, je vais pouvoir directement être redirigé sur la classe qui est AtomStatusBar par rapport à la nomenclature qui a été mise en place. Et directement, avec l'autocompletion qui est faite côté VS Code, je vais pouvoir directement en quelques clics récupérer toutes les informations qui ont été générées automatiquement. C'est aussi là où on essaie de non seulement se rapprocher du stack côté développeur, mais aussi utiliser l'IDE qu'ils utilisent et du coup la force que cette IDE a pour compléter du code qui n'est pas forcément existant. Donc ça, c'était le premier scénario où le code n'est pas forcément existant et qu'il est... proposé de façon automatique par Figma, que ce soit via un plugin ou via nos outils internes. Le deuxième monde, c'est tout simplement, je vois ici que mon code, côté CodeConnect, a déjà été créé.

46:41 Si du React, donc admettons que je sois dans mon code repo et je vais sélectionner mon langage sur du React, Voilà, parfait. Et là, je vais pouvoir tout simplement coller mon bouton et faire en sorte que ce bouton, non seulement il ajoute le code que j'ai déjà créé automatiquement ici, si via CodeConnect, vous aviez mis en place du code de différents langages, donc ici, je n'ai que du React, mais si, mettons, je l'avais ajouté en Angular, parce que peut-être j'ai différents frameworks, j'ai différentes versions de frameworks, j'ai différentes legacies qui ont été créées, où j'ai une dette technique avec beaucoup de différentes langues et de thématiques en interne, c'est quelque chose dans lequel si j'avais du SwiftUI ici, c'est quelque chose que je pourrais voir aussi et l'ajouter automatiquement. Et c'est à peu près tout. Je pense qu'on a à peu près couvert. Je veux laisser du temps aussi pour les questions-réponses et la section Q&A pour la fin. Mais j'espère que c'était assez complet et que ça a pu permettre de vous donner une idée de comment nous, on aborde aussi cette résilience, de cette conduite de changement qu'on a sur...

47:47 Sur ces thèmes avec les propres clients qu'on accompagne en France, donc des PME aux grands groupes européens et mondiaux. Parce que je trouve ça quelque chose de fascinant, c'est-à-dire qu'il y a encore deux ans, Figma, était vraiment orienté côté design. Six mois après avoir commencé, je me retrouve à plonger dans le monde de la communauté des développeurs et me rends compte que je dois complètement changer mon rôle. Donc même moi, le côté résilient, c'est quelque chose que j'ai vécu moi-même en première expérience et c'est aussi pour ça que j'étais vraiment content de partager avec vous mon expérience et participer à cette masterclass. Merci Emmanuel. Alors il y a Rémi qui souhaite un complément. Du coup, je vais me permettre de répondre sur sa partie. Donc il dit que ça marche ce que tu montres par rapport à des... Quand il n'y a pas trop d'équipes en fait. Et qu'il y en a plus. Mais en gros, c'est le bazar quoi. Tout le monde fait un peu comme il ou elle veut. Moi, de ma fenêtre, pour moi, j'ajouterais du process dans ce cas-là.

48:50 Et c'est plus le storybook, le design system qui est de façon collégiale et faire en sorte que tous les nouveaux composants soient tirés du design system. Et c'est au moment où on enrichit le design system que... Que ça doit respecter les normes. En vrai, c'est un problème qui est dans pas mal d'entreprises, donc c'est vrai qu'il n'y a pas non plus de solution magique. Ce n'est pas si nouveau que ça. Effectivement, je te l'accorde entre la question dans le chat et ton commentaire. Je suis entièrement d'accord. C'est-à-dire qu'il y a une vraie partie... C'est souvent... Souvent, ce dont je suis aussi responsable et mon équipe est responsable avec nos clients, c'est qu'il y a cette conduite de changement, mais c'est aussi... accompagner nos clients à réfléchir différemment. C'est-à-dire, c'est comme ça qu'ils réfléchissaient quand, admettons, leurs développeurs allaient dans Figma à l'époque, mais dans une sorte d'OS qui ne leur parlait pas forcément. Donc il y a une part d'éducation, il y a une part d'adoption, mais il y a aussi une part de changement, c'est-à-dire pourquoi moi en tant que dev je devrais encore adopter un nouveau fichier, pourquoi ce n'est pas eux qui viennent et m'aider alors qu'en fait c'est aussi une collaboration entre les deux.

49:56 Et c'est la thématique numéro un que j'ai, allez, numéro un on va dire. avec les clients que j'ai la chance d'accompagner, c'est qu'il y a des problématiques qui se répondent avec un côté tooling, donc avec le côté outil, où là-dessus, moi, je peux peut-être donner des feedbacks à notre équipe produit et leur dire tel client a besoin de ceci et peut-être on le revoit arriver dans le produit. Et il y a aussi toute la deuxième partie où on se rend compte que le fossé entre designer et développeur est énorme. Et en fait, comme tu le dis, ça passe par des process. Ça passe par peut-être inviter un ou une développeur un peu plus tôt dans le process, sur le côté, dans la phase de conception, dans la phase d'idéation, où la développeuse va dire, en fait, là, ce que vous me proposez, ça ne va pas être possible parce que le backend va me dire l'inverse. Vous pouvez rêver, mais ça ne va jamais arriver. Plutôt que designer ça et arriver trois semaines plus tard pour dire en fait on doit tout reprendre de zéro. Ou vice versa, avoir, mettons, un designer arriver en fin de process et donner un peu de réalité à ce qui a été fait et pourquoi c'est différent par rapport à ce que j'ai imaginé.

51:08 On a aussi une question de Rémi, un autre, qui pose la question du workflow idéal par rapport aux traductions, sans avoir à dupliquer toutes les vues. C'est une très bonne question. J'ai moi-même un background en localization et en traduction, donc ça me touche personnellement. C'est quelque chose que je trouvais assez fascinant et je pense qu'il n'y a pas de bonne réponse. Ce serait assez présomptueux de ma part de dire c'est comme ça qu'il faut faire, dans le sens où j'ai vu des clients qui avaient des thématiques comme ça à petite échelle réussir moins bien que d'autres à grande échelle. Donc c'est vraiment... C'est assez difficile de dire qu'est-ce qui peut fonctionner, mais je peux donner des pistes. Parce que je pense que c'est aussi ce que ce deuxième Rémi cherche. Je mettrais vraiment en avant deux choses. Je dirais la première chose, c'est utiliser les variables.

52:08 Les variables permettent vraiment d'avoir, mettons, un token, donc par exemple, quelque chose en copywriting. Ça peut être un exemple simple que j'ai donné un peu plus tôt, add to basket, ça peut être, mettons, traduit avec différents modes, donc différentes variations, que ce soit, mettons, la première variation en français, donc« ajouter au panier», en anglais, ou bien« añadir a la cesta» en espagnol, etc. Et se retrouver... à utiliser ces variables avec autant de modes que de langues qui sont utilisées dans les thèmes de localisation. Donc admettons, vous êtes un groupe français, vous êtes implémenté en Europe ou dans le monde, vous avez une dizaine de langues, essayer d'utiliser les variables de telle façon à ce que vous les déclinez sur les différentes... Donc, mettons, vous utilisez un outil de TLS, comme, je ne sais pas moi, Localize, par exemple, Eux, ils ont une API, on a une API, ces variables peuvent être utilisées dans notre API.

53:08 Notre API, elle est en read et en write, c'est-à-dire que si vous avez vos strings qui sont déjà traduites quelque part, vous pouvez les basculer directement et modifier le fichier Figma au sein de ces variables. Et c'est ce que j'essaie de mettre un peu en avant un peu plus tôt, c'est-à-dire avoir une source de vérité qui soit prise en charge, que ce soit, si vous décidez, mettons, une source externe et la source de vérité, donc admettons votre outil de traduction ou de localization comme TLS, admettons, on va prendre Localize encore comme exemple, Vous prenez ces strings, vous les poussez dans Figma, et ça permet de faire ça. La deuxième, ce serait utiliser des branches. Je ne sais pas si vous utilisez des branches, c'est à partir du plan organisation dans Figma, donc ça peut mettre des barrières parfois, mais c'est quelque chose que je conseille souvent pour expérimenter sur... C'est le même principe qu'un code, au final. C'est-à-dire, on expérimente sur un fork, tout ce qu'on touche, ne touche pas le master et c'est à la fin uniquement quand les traductions ont été validées, quand le passage en prod a été fait, que le ou la dev flag ça comme complété.

54:18 Que maintenant moi ça me donne une indication en tant que designer pour me dire c'est bon tout ça ça a été carré et maintenant je fais je merge cette branche et je la mets dans le master de telle façon à ce que maintenant je sais que ce qui est en prod et ce que j'ai en design c'est iso et j'ai pas à me prendre la tête et réfléchir qu'est ce qui a changé ou pas j'espère que ça peut ça a pu répondre Je t'invite, si ce n'est pas... Ça, c'est suffisant à rajouter un commentaire. En tout cas, merci beaucoup, Emmanuel. C'est super clair. En tout cas, ça donne envie, ça a l'air super complet. Moi, j'ai bien aimé le côté... Parce que c'est vrai que je trouve que c'est le bazar, Figma. J'ai toujours pas vu. Ça l'est, hein. On n'en voit rien, ça part dans tous les... Il y a 10 000 histoires parallèles. Donc le fait de figer, là, c'est carrément canon. Et la partie diff, ça j'ai adoré. J'aime bien aussi les intégrations qu'il y a avec Jira, avec Storybook.

55:21 C'est top. J'ai quelques questions. Alors, vu qu'on a encore quelques minutes, attends, je regarde s'il n'y en a pas d'autres qui sont pris, enfin, d'autres, parce que du coup, les gens sont pris haut, c'est un pouce, ça va. Alors, du coup, tu parles pas mal d'alignement, et du coup, j'ai le sentiment qu'effectivement, ça doit rapprocher d'avoir un outil commun. Entre les devs d'Affront, surtout j'ai l'impression, vu le code qui est là, et les designers. Et du coup, je me pose la question des autres. Donc, tu as parlé un peu du marketing. Je vais assimiler à produit ici par rapport au warning. Je ne sais pas d'ailleurs s'ils ont des droits pour modifier en live ou si le modèle, le design, c'est... Le videur, la videuse de toute modification. Il n'y a que les devs qui ont une porte dérobée là-bas pour faire d'autres choses. Et la question que je me pose derrière ça, c'est, vu que ça a l'air très séquentiel dans le sens... Le designer ou la designeuse fait son truc, après on affine et on passe au suivant, j'aurais un peu peur que ça renforce des silos, et que ce soit du coup l'inverse de la promesse qui se passe.

56:28 Je ne sais pas si tu as des retours d'expérience par rapport au client. Vous avez déjà ou des choses comme ça ? C'est vrai que ça peut être un risque et qui a été vraiment pris en compte par nos équipes produits. Pour répondre à la première partie de ta question, sur le côté marketing, on a vraiment la vue viewer, c'est-à-dire une personne qui ne peut pas expérimenter le côté DevMode, donc pas avoir cette vue, on va dire, très améliorée. Mais juste voir le fichier et le regarder. Dans ce cas-là, c'est vraiment une licence gratuite, pas besoin de payer, c'est 0€, 0$. Mais ces personnes peuvent quand même commenter. Donc, arriver sur le fichier, appuyer sur la touche C ou en haut à gauche, commenter, et juste ajouter un commentaire exactement au bon endroit. Donc ça permet aussi d'avoir de la collaboration, même de personnes qui, on va dire, ne pas forcément passer par le côté videur-videuse. Dans un deuxième temps, ta question était principalement sur renforcer les silos.

57:28 C'est un risque. Je pense que ça peut arriver. Mais c'est plus sur du long terme. Je pense que sur le court terme et le moyen terme, ça aide à avoir les personnes au même endroit. Ce que moi, je trouve personnellement très utile, et je l'ai vu et j'ai eu cette expérience vraiment, comme ils disent en anglais, first hand, vraiment, j'ai expérimenté le problème, c'est, C'est le côté multiplayer, c'est ce qu'on appelle multiplayer à Figma, c'est quand je suis dans un fichier, quand vous voyez mon autre... de curseur en bas à droite, en fait, quand on se retrouve dans un sprint ou mettons dans un design crit, on doit poncer le design et essayer de pousser le produit jusqu'à ce qu'il casse ou à essayer de dire ça c'est pas bon, ça c'est pas bien. On va voir vraiment toutes les personnes qui sont en train de s'orienter dans le fichier et je trouve que C'est dans ce genre de moment-là où la personne arrive de très loin dans le cycle de développement. Donc, admettons, une dev arrive très tôt dedans.

58:31 En fait, je peux juste cliquer en haut à droite. Donc, admettons, Florence, tu es la dev qui s'occupe du design que moi, j'ai designé. Je vais pouvoir juste cliquer sur toi et te suivre. Restez comme ça et voir exactement qu'est-ce qui t'intéresse. Commencer une discussion même au sein de Figma, c'est une fonctionnalité qu'on a sur tous les plans. Où je peux juste chatter pour me dire, dis-moi ce que tu vois, dis-moi ce qui ne va pas. Et c'est comme ça que je vois ces silos se réduire d'une façon ou d'une autre. D'accord. Du coup, il y a des fonctionnalités qui permettent quand même... De ne pas se perdre et de se retrouver. Et du coup, sur le temps de cycle, parce que du coup, comme c'est très fin, et j'ai l'impression que les maquettes sont ultra fidèles, vraiment effectivement sur du pixel parfait, je me dis que ça rallonge aussi le temps de design. Et plus c'est long, plus ça va raccoter, moins on aura envie de prendre le temps de le modifier. Ou de l'améliorer. Genre, ah, c'est bon, on a eu un mois pour avoir le... De Randolph, alors on va surtout rien trouver. Est-ce que tu as des conseils peut-être en amont ou comment faire pour éviter ça et tu vois que ça reste agile, itératif en fonction des feedbacks des uns des autres ou même est-ce qu'il y a des user tests ?

59:42 Qu'est-ce que tu peux me dire par rapport à ça sur comment on améliore le produit en prenant en compte un peu les feedbacks des équipes différentes? C'est vrai qu'il y a aussi ce risque d'augmenter ce cycle de design. Ça passe vraiment par une phase d'éducation, c'est-à-dire que, J'ai même moi été surpris d'apprendre des bonnes pratiques que certains designers et designers ne mettaient pas forcément en pratique. Et c'est ce qui est assez difficile dans le rôle que j'ai, qui a pas mal évolué. C'est-à-dire qu'au début, je faisais pas mal d'éducation sur les designers et à la fin, je me retrouve à éduquer les designers comment les devs fonctionnent. Et vice versa. Donc on peut se retrouver à devoir développer une conception qui est de plus en plus, comme tu le dis, fidèle avec des prototypes fous. C'est vrai qu'on peut être tenté de ne plus toucher à un design system, mais je pense que c'est, C'est là où vraiment il y a un souci d'adoption. Est-ce que le focus, c'est l'adoption du design system?

1:00:46 Est-ce que c'est la fidélité? Ou est-ce que c'est qu'on fasse tout de façon pixel perfect? C'est souvent, on est un peu vraiment à la croisée des mondes. Et là, ces questions, je les trouve extrêmement pertinentes parce que c'est vraiment... Sur de la bonne maturité à la fin de la maturité. Et assez surprenant, personnellement, je trouve ça extrêmement surprenant de voir des clients qui, pour moi, de mon avis, sur le spectre de tous les clients, se jugent comme peu matures et qui, en fait, ont un design system dans tous les sens extrêmement carré où ils ont très peur de toucher quelque chose. Mais en fait... Ça leur permet d'être... Ça leur permet d'être agiles, mine de rien. Oui, clairement. Parce qu'après, tu as juste à... Tu fabriques plus vite. C'est ça. Je vois qu'on dépasse le timing d'une minute. Je vois qu'il n'y a pas d'autres questions. De toute façon, de ce qui était, je crois qu'il faut vraiment respecter le temps. Les gens ont sûrement faim. Moi aussi. Beaucoup. Moi aussi.

1:01:48 Je vais manger. Merci beaucoup pour la présentation. C'était très intéressant et très complet. Merci pour vos questions. Et si vous avez d'autres interrogations, je crois que les contacts ont été laissés. Bon, bonne journée à tout le monde. Bonne journée. Bye bye.