Les designers et le dev

Bruno:
Tout le monde veut devenir dev. Après les outils no-code, voilà que les designers s'y mettent aussi grâce au dev-mod de Figma. Leur objectif, générer du code presque prêt à l'emploi pour simplifier la vie des développeurs. Mais simplifier ne veut pas toujours dire faciliter. Mais alors, le dev-mod de Figma va-t-il vraiment révolutionner notre collaboration ? Faut-il encore savoir coder quand tout semble déjà mâché ? Et surtout, peut-on vraiment générer du code sans jamais y toucher ? Pour répondre à ces questions design-driven, je ne reçois pas Léonard de Vinci, mais ils s'y connaissent en pont entre deux mondes. Lucie et Anthony, bonjour.

Anthony:
Bonjour Bruno.

Bruno:
Alors, est-ce que vous pourriez vous présenter pour quelqu'un qui ne vous connaîtrait peut-être pas ? Et on va commencer par Lucie.

Lucie:
Avec grand plaisir. Donc Lucie Bordelet, moi je suis chez Figma et je suis responsable de l'Europe. Et je suis absolument vraiment ravie d'être ici ce matin.

Bruno:
Eh bien, on est ravis de te recevoir aussi. Et Anthony, à toi ?

Anthony:
Donc moi, Anthony, je suis leader technique chez OnePoint, au sein d'une communauté d'à peu près 300 personnes qui est le groupe designer, développeur, chef de projet. Et donc j'encadre des équipes dans le cadre de projets de développement d'applications. Donc au quotidien, je code, j'apporte mon aide aux développeurs, je fais l'architecture, je fais les avant-ventes. Et le gros point, je pense, différentiant qu'on a chez OnePan, c'est que vraiment on a ces dispositifs intégrés où au quotidien, sur le même plateau, on a les designers, on a les développeurs. Donc la collaboration, c'est au sein de notre ADN. D'où le sujet du DevMod et de Figma qui nous intéresse aujourd'hui.

Bruno:
Avant de commencer à parler de ce DevMod de Figma, peut-être que pour quelques personnes qui ne connaîtraient peut-être pas Figma, est-ce que Lucie, tu peux nous redresser un peu un tableau rapide, parce que je pense que beaucoup de gens connaissent, mais un peu de ce qu'est Figma ?

Lucie:
Oui, donc à l'origine effectivement, Figma c'est un outil pour les designers, pour designer des produits digitaux. C'est aussi un outil d'idéation et donc ce dont on s'est rendu compte à l'usage c'est que finalement sur cette plateforme qu'on pensait être pour les designers au départ et après ça qu'ils donneraient leur design aux développeurs, il y avait 30% des utilisateurs qui étaient des développeurs mais depuis longtemps en fait et donc les développeurs s'intéressent au design parce que leur vie et leur capacité à développer le produit en question va beaucoup dépendre de leur relation avec le designer, donc au départ c'était ça Et depuis effectivement deux ans quasiment maintenant, on a lancé un produit qui s'appelle DevMode, dont l'idée est de dire comment est-ce qu'on peut améliorer la collaboration entre les deux métiers, qui quand même parlent des langages un peu différents, même si le but c'est de faire le même produit à la fin, tout en permettant aux deux côtés de rester dans le flot. Parce qu'effectivement la collaboration c'est super mais se parler tout le temps c'est pas forcément nécessaire et donc pour nous c'était vraiment cette idée là et c'est ce qu'on cherche à faire c'est de la collab où tout le monde reste quand même, au delà d'un expert vraiment quelqu'un qui maîtrise son art ou son ou sa façon de faire quoi.

Bruno:
Et alors sur ce, justement, le fait qu'il y ait différents profils qui utilisent le même outil, parce que nous, en tant que dev, on a quand même besoin que les choses soient organisées d'une certaine façon. Quand on veut créer nos composants, on a besoin que les choses soient, il y a un certain type de structure. J'imagine que chez les designers, c'est peut-être pas forcément la même approche. Est-ce qu'il y a des moyens de faire converger cette approche d'organisation des éléments ?

Lucie:
Oui, alors c'est marrant, il y a quelques années, on a lancé pour les designers un truc qui s'appelle Auto Layout. Et en fait, Auto Layout, ça vient du monde des développeurs. Donc en fait, on essaye de se faire rapprocher quand même des façons de penser qui se rapprochent. Et donc, on a commencé en faisant bouger un peu les designers, sans qu'ils s'en rendent compte, en leur mettant des petites idées qui viennent du monde des devs. Et effectivement, l'idée, ce n'est pas de dire qu'on a des artistes et des techs. Ce n'est pas du tout ça. Le monde aujourd'hui, des gens qui font des produits digitaux, il faut arriver à parler à peu près le même langage, même si on est sur des langages différents. Donc oui, on peut faire des choses. Et il y a beaucoup de gens chez Figma qui pensent à ça. Comment est-ce qu'on ramène des notions de la tech vers les designers ? Parce qu'en fait, ça devient nécessaire. on fait pas de l'art pour de l'art, donc au départ c'était ça et puis un ensemble de choses qu'on a mis en place, au début tu générais un peu des petits codes snippets de rien du tout, quasiment inutilisables les premières versions sur Figma tout le monde disait un peu comme l'EI, ça sert à rien, votre truc ça correspond pas et puis au fur et à mesure on se rapproche de plus en plus éventuellement de votre propre code dans votre propre, dans votre propre langage, un peu l'air de rien tu vois il faut y aller par étapes et finalement les gens finissent par se rendre compte qu'ils parlent un langage qui est de plus en plus proche et comme on est quand même sur des professions notamment dans le design très jeunes, ils s'en rendent même pas compte il y a une plasticité qui est là et du coup ils s'adaptent et en.

Anthony:
Fait typiquement aujourd'hui les designers nous on les forme à utiliser les variables côté Figma donc ils utilisent les variables, les design tokens, pour citer leur couleur parce que nous après on reprend ça et on n'a pas à le faire 10 000 fois et puis derrière notre color c'est white c'est black ou c'est le nom de la couleur spécifique, c'est le nom de la taille spécifique, par contre ça demande de la rigueur c'est vrai que c'est quelque chose que les designers n'avaient pas trop, c'est pas les plus rigoureux le nombre de frames qu'on a vu qui s'appelait frame 1, frame 2, frame 3 donc il y a toute cette étape d'acculturation et de dire ok, nous on a besoin que ça soit cadré effectivement. Frame 1, c'est pas frame 1. Frame 1, c'est la home. Frame 2, c'est la page contactez-nous, etc. », vos composants ils sont bien nommés effectivement vous utilisez des composants vous avez cette notion de composants réutilisables et vous mettez pas des designs que vous refaites à chaque fois que vous copiez-collez mais vous faites un composant et vous l'instanciez dans chaque page, vous utilisez des variables et des tokens pour faire en sorte que on ait la même couleur partout parce que j'ai vécu dans ma vie des designs où tu prends deux pages et entre les deux pages c'est pas le même noir sur le texte tu te dis mais comment t'as fait ? T'as une fonction variable, tu mets juste le nom de la couleur et c'est bon ça marche et donc il y a toute cette phase d'acculturation que nous on a fait, et notamment avec Figma qui nous a accompagné dans le dev mode, l'accompagnement premium qu'on a eu au tout début du dev mode un peu avant que ça soit ouvert à tout le monde. Et on s'est rendu compte que les devs il fallait qu'ils s'adaptent à cette nouvelle interface qui était plus proche de leur IDE et donc avec des changements effectivement dans l'usage il fallait que les designers eux, parlent le même langage comme on le disait il fallait qu'ils s'appuient sur les fonctionnalités de Figma qui sont pensées pour ça pour nous simplifier la vie parce qu'en fait demain quelqu'un qui connait pas du tout Figma qui prend juste l'outil, qui trace des carrés qui met des boutons et qui utilise aucune des fonctionnalités c'est inutilisable comme un code copié-collé depuis Google ou comme un code fait par ChatGPT qu'on comprend pas donc il y a vraiment une, petite courbe d'apprentissage Mais une fois qu'on s'est entendu sur comment on structure nos pages, comment on structure nos composants, quels sont les variables qu'on utilise, derrière, ça glisse.

Bruno:
Alors, je pense qu'on verra peut-être dans un second temps les sujets de la qualité du code qui est généré, parce que c'est forcément une question qu'on a tous. Mais avant ça, moi, j'aimerais bien creuser le sujet de l'impact côté designer. Ce que je vais dire par là, c'est que on voit depuis quelques années une tendance du ASCode partout on a l'infra ASCode on a déjà même reçu quelqu'un ici qui nous a présenté l'architecture ASCode donc c'est pouvoir générer des choses avec quelques lignes de code et qu'après les choses se fassent toutes seules donc là on est presque sur d'une fois dans ce que tu décrivais Anthony sur cette notion de, ces variables, ces créations de composants directement dans Figma et autres on est presque sur du design ASCode tu nous disais qu'il y avait beaucoup de jeunes, dans ces métiers-là, donc il y a une certaine plasticité. Une question peut-être naïve, mais est-ce que cette approche hyper structurée n'a pas, d'une certaine manière, contraint ou limité les capacités créatives justement de tous ces designers et de tous ces créatifs ?

Lucie:
Alors ça c'est marrant, c'est un vieux débat. Est-ce que le fait d'avoir un cadre limite ta créativité ? Tu as deux points de vue. Le point de vue qui dit non, au contraire, quand tu as un cadre, tu justement, tu t'exprimes dans un cadre, mais ça n'empêche pas du tout de s'exprimer. Il y a des gens qui vont être en dehors de ça. La réalité de Figma, c'est qu'on design des produits digitaux. Donc en fait, ce sont des produits qu'il va falloir coder, en tout cas qui sont sur des architectures. On n'est pas dans un monde où on fait un crayon et un papier. Et donc il faut accepter le cadre enfin je pense qu'il faut accepter le cadre on produit des outils digitaux après effectivement si c'est pour produire un site web extrêmement simple, on aura très peu de limitations techniques, peut-être qu'on pourra faire quelque chose qui va passer directement du design vers le code tout seul. Mais je pense que c'est pas ce que font la majorité de nos clients nous la majorité de nos clients sont quand même des pros qui font des choses complexes si tu penses aux produits digitaux tout le monde pense au site internet, le truc le plus simple l'appli, mais c'est aussi l'intérieur de ta Tesla. Et ça, c'est un produit digital un peu compliqué, quand même. Donc, oui, il y a des contraintes, mais ça ne t'empêche pas de faire un truc qui est, au-delà d'être beau, parce que ce n'est peut-être pas l'objectif, extrêmement user-centric. Et c'est là que cette user-centricity, elle est intéressante, parce qu'en fait, rapprocher les designers et les devs, ça aide énormément pour faire quelque chose qui est complètement fluide derrière et qui est agréable à utiliser. Et il y a quelque chose que les designers et les développeurs n'aiment pas, c'est le redo, c'est le rework, c'est y repasser dix fois, parce qu'en fait, c'était super beau, mais ça ne correspondait pas, je n'ai pas compris ce que tu voulais, c'est deux noirs différents, etc. Et ça, je pense que tout le monde est prêt, ou beaucoup de gens sont prêts à accepter le cadre pour éviter le rework ou les heures de discussion sur ce que tu as bien voulu voir.

Bruno:
Donc, il y a une, acceptation aisée de ces pratiques qu'on a côté dev, parce qu'en fait, ça leur facilite aussi la vie côté design. Est-ce qu'à l'inverse, il y a des habitudes, des comportements, des méthodes, des façons de faire côté designer qui ont transpiré côté dev ?

Anthony:
Je ne sais pas s'il y a des méthodes qui ont transpiré, mais je constate quand même qu'on pense souvent que le back-end, c'est plus compliqué que le front-end, etc. Travail front je parle de manière générale dans l'imaginaire des gens et même des développeurs ils sont tous en mode ouais le back end c'est plus dur c'est plus machin, en fait pour le front end il y a quand même un oeil à avoir, une précision quelque chose qui fait que il faut une attention au détail, il faut des choses comme ça et donc quand le designer design bien, son produit et fait les choses correctement ça nous simplifie aussi tout ça et ça fait que les gens ont plus facilement les informations dont ils ont besoin pour faire l'implémentation et tout. Et donc dans les détails, c'est beaucoup plus précis. C'est pas je regarde et je dis bon c'est à peu près 12 pixels non en fait j'ai une variable qui me dit c'est 12 pixels et puis celle là c'est 2 fois cette là, et comme ça j'ai un truc vraiment bien aligné, bien cadré sauf dans des cas très spécifiques où on va être un peu plus créatif mais, donc je pense que c'est effectivement les devs qui ont contaminé les designers, pour que ça nous simplifie le travail mais on augmente, l'attention du dev en facilitant son travail on augmente la qualité de manière mécanique.

Bruno:
En fait on évite aussi le fameux rework qu'évoquait Lucie, c'est que le dev n'a pas à faire le travail que le designer a fait dans son coin et du coup il fatigue.

Anthony:
Et en fait surtout il a moins besoin de poser des questions on parlait tout à l'heure un peu du flow le fait en fait de prendre son design de commencer à l'implémenter et puis de se rendre compte que ah bah en fait là j'ai une question là j'ai une question, là j'ai une question, ça nous interrompt on est obligé d'aller poser la question peut-être interrompre quelqu'un avoir un certain délai avant la réponse, le temps d'avoir la réponse de se remettre dedans, on perd énormément de temps et nous ce qu'on veut c'est mettre dans la main des utilisateurs notre produit, la seule valeur du code c'est en prod. Nous on est en bout de chaîne donc souvent les décisions sont déjà prises avant nous, donc nous on se retrouve implémentés donc c'est ça qui est intéressant aussi dans la démarche c'est comme on parle souvent de shift left dans le cloud, dans l'infrastructure là on fait aussi un shift left des devs, c'est dès le début on implique les devs dans le design on peut même donner des avis en mode ça ça va être sur l'implémenter ceci cela et donc on crée déjà dès le début la synergie les échanges et, une fois qu'on a fait ça, on passe à l'implémentation, on va plus vite on met dans les mains des utilisateurs et effectivement si ça ne correspond pas on peut s'adapter mais on a eu déjà plusieurs checkpoints au fur et à mesure qui nous permettent de se dire ok on va dans la bonne direction, à une époque c'était moi dans mon passé j'ai travaillé dans d'autres sociétés les designs étaient finis à date à date J le client avait 5 jours pour valider et puis après on les donnait aux développeurs puis là on découvrait le truc on faisait mais je peux pas utiliser ça moi, y'a rien qui va j'ai pas les mesures c'était compliqué aujourd'hui on a accès au Figma hyper tôt on peut commencer à regarder donc les designers sont toujours un peu pudiques ils aiment pas trop nous montrer quand c'est pas fini Donc souvent ils aiment bien attendre qu'ils mettent soit « Available in Dev » soit « Ready » pour qu'on puisse regarder. Et encore une fois, je pense que la vision qu'on a permet d'enrichir aussi le produit digital. La qualité du produit, ça dépend de tous les points de vue qui s'additionnent. Plus on a de points de vue, plus on a de gens qui confrontent et qui challengent, plus on va faire en sorte d'avoir un produit qui est bien conçu.

Lucie:
Et alors c'est marrant, cette pollinisation, c'est aussi dans les équipes. Ce qu'on voit dans les grosses équipes design en France, c'est qu'en fait il y a un, voire plusieurs développeurs, ou anciens développeurs, mais en fait développeurs, parce qu'on ne peut pas être anciens développeurs, on l'est, qui rejoignent les équipes design. Effectivement pour regarder les composants, regarder un peu comment on organise les choses, pour être très en amont et sans parler d'un produit particulier, parler d'une organisation, de comment on set up tout ça pour que ce soit scalable. C'est pour ça que je parle de grosses équipes. Plus les équipes de design sont importantes, plus on est sur des entreprises qui ont beaucoup de produits digitaux, plus on va commencer à avoir des techs dans les équipes design. Parce qu'en fait, ça devient nécessaire, effectivement.

Bruno:
Et puis ça facilite aussi, ça augmente la satisfaction côté client ou demandeur parce que tu l'évoquais, quand la maquette est évadée par le client et qu'on l'envoie après au dev et qu'il dit bah non en fait là ça marche pas, faut changer ça il y a un côté très déceptif du client qui dit bah en fait faut revenir sur les maquettes parce que et puis on a l'impression que c'est la faute du dev parce que c'est lui qui dit que ça marche pas mais en fait c'est juste, il fallait se voir dès le début quoi.

Anthony:
C'est exactement ça et ça on l'a vécu dans toutes les étapes du développement donc c'est pour ça qu'on rassemble le plus tôt possible et comme ça, on va plus vite. Ouais.

Bruno:
T'évoquais tout à l'heure, quand on parlait effectivement de cette notion de variable, de composant et que du coup, maintenant, c'est partout dans Figma. Il y a un petit étonnement de ma part, c'est que alors c'est peut-être réservé aux grands groupes, mais tu vois, moi j'ai déjà vu souvent des boîtes avoir tout un design book ou un design système, avec des choses très précises. Ça c'est ma police d'écriture, ça c'est ma couleur, ça c'est mes logos, voilà, comme on utilise. Tu vois, il y a des choses qui étaient quand même hyper cadrées. Est-ce que ça a été pendant un moment réservé en fait à ceux qui avaient les moyens de faire ce genre de choses et qu'en fait pour le commun des mortels on faisait encore les choses en version 1.1, en version finale, version finale finale, version finale 2, En fait.

Lucie:
C'est marrant parce que l'histoire du design system, effectivement, moi, je peux te dire, sans les nommer, j'ai encore des clients très grands qui me disent, je dois aller expliquer à des gens qui ont l'argent, pourquoi ça a de la valeur d'avoir un design system. Quelle est la valeur du design system ? Alors, tu vas avoir des points de vue brand, pour la cohérence de l'expérience, pour la cohérence de la marque. Et plus la marque est forte, plus évidemment, on a envie que ce soit super cadré. Mais c'est un investissement, parce que faire tous ces composants, les maintenir, parce que faire un truc vite fait, tout le monde peut le faire, mais le maintenir dans le temps, s'assurer que tout le monde l'utilise. Parce que oui, tu peux faire un design system magnifique, et plus personne ne l'utilise derrière. Donc, mettre en place tout ça, finalement c'est une orga qui ça coûte et donc t'as encore des efforts à faire donc est-ce qu'on est beaucoup mieux qu'il y a 3 ans de ce point de vue là je pense que oui parce que je pense que les gens commencent à avoir l'intérêt notamment parce que ça accélère le développement donc le design system quand il était que pour les designers c'était d'une certaine façon plus difficile à vendre que quand on dit ce design system très cadré, très utilisé, permet derrière de produire les outils beaucoup plus vite et c'est quand tu fais le lien entre la valeur du design system, et le code que réellement t'arrives à entre guillemets vendre ton projet et montrer la valeur du truc hum. Donc, je pense qu'on va beaucoup plus loin qu'on a été, mais on a pas mal de plugins aujourd'hui qui sont développés. L'autre lien entre les développeurs et Figma, c'est que Figma a énormément de plugins. Donc, il y a énormément de développeurs qui développent des plugins pour Figma. Et donc, il y a pas mal de plugins, notamment des plugins privés dans les boîtes, sur quelle est l'utilisation réelle du design system. Nos clients les plus avancés, des gens comme Uber, te lancent en réel des espèces d'outils qui regardent précisément. Voilà ce qu'il y avait dans Figma, voilà ce qui est sorti, quel est le pourcentage, de match entre ce qu'il y a d'un côté et ce qu'il y a de l'autre, si t'es à moins de je sais pas quel pourcentage, tu passes pas et on repasse. Et en fait, à force de mettre ça en place, les gens du coup se disent, moi j'ai envie d'éviter le rework, donc je vais faire de plus en plus attention à la façon dont je m'organise, j'organise mon design system pour que cette charnière se fasse vraiment de façon très smooth. Et derrière, le but du jeu, le but très simple c'est gagner en rapidité et gagner en exécution c'est l'objectif de tout le monde, c'est comment je pense un produit et je le livre le plus vite possible, de la meilleure qualité possible.

Bruno:
J'aime bien aussi l'idée que tu as évoqué tout à l'heure que la collaboration c'est super mais se parler tout le temps c'est pas forcément idéal et c'est ce que tu as évoqué aussi Anthony c'est une interruption permanente, et en fait ça montre bien qu'on est effectivement sur des métiers qui sont quand même très humains mais qu'on a aussi ce besoin quand même de concentration et que c'est très bien d'échanger avec ses collègues de savoir ce qu'ils font, leurs problématiques, leurs sujets leurs enjeux, mais devoir constamment se déranger pour se revalider un truc ça, ça ne fait avancer personne.

Anthony:
C'est ce qui tue la productivité le plus possible.

Lucie:
Et la motivation et.

Anthony:
D'ailleurs ça me fait penser que, Figma quand ça a commencé on se connectait beaucoup sur l'interface web, il y a l'application qui est sortie aussi que tu peux installer en desktop aujourd'hui il y a le plugin Figma dans VS Code donc en fait t'as même plus besoin de sortir de ton VS Code, t'es dans ton IDE tu vois directement tes designs qui ont été validés tu peux aller choper les informations dont t'as besoin pour faire ton implémentation, et t'as pas d'interruption même de switch de contexte, donc quand tu te dis ok aujourd'hui je vais travailler sur cette partie là t'ouvres ton VS Code, t'as directement les tâches que t'as à faire entre guillemets puisque t'as la liste des designs qui sont, qui sont prêts et tu peux te lancer t'es pas obligé d'aller dans un autre outil et d'aller chercher x ou y et les plugins permettent ça aussi d'amener encore au plus proche de l'environnement du dev, le dev il veut qu'on lui prémâche le travail enfin nous notre je parle de manière générale notre taf c'est de répondre à un besoin, si on répond à un besoin en écrivant du code ça nous excite un peu, si on a. Un besoin qui n'est pas clair, un besoin qui est trop simple, un besoin qui est ceci, cela. On va avoir tendance à rajouter des complications pour s'exciter un petit peu. Donc si on nous pré-mache le travail qu'on peut le plus vite possible finir nos tâches et après aller faire autre chose. Jouer à Valorant, faire ceci, cela, mais être payé pareil. Nous, ça nous arrange. Donc typiquement, le fait de pousser ça dans l'IDE, le fait d'avoir des plugins qui vont nous pré-générer des choses comme ça. On s'assure qu'on a des choses de qualité. on s'assure qu'on a une charge de travail qui est réduite et donc on peut faire plus de choses et les devs, ils adorent être surchargés ils adorent avoir 150% de tâches sur le dos et de se dire tiens, je vais me défoncer, je vais tout dépiler et puis je vais finir en avance et après je fais d'autres choses, c'est la curiosité intellectuelle qui est le moteur de ce métier et donc on aime être alimenté et quand on a rien à faire, on s'ennuie vite.

Bruno:
Et ce qui est marrant c'est qu'il y a cette c'est vrai que c'est un mindset qui est très particulier ce mindset de développeur et développeuse, il y a un côté un peu fainéant mais en même temps on aime pas être inactif.

Anthony:
C'est des divas c'est compliqué les devs on est des divas et on est super, paradoxal parce qu'effectivement le meilleur dev c'est le plus fainéant parce qu'il va faire son travail vite et bien comme ça il a pas à le refaire mais en même temps il faut énormément de travail mais pas trop non plus il en faut.

Bruno:
Plus que de normal mais pas, c'est une balance difficile à trouver.

Anthony:
C'est ça, et donc les outils dont on a parlé, Figma, Copilot, etc. nous permettent justement de faire plus, de faire plus vite. Moi, je le sais, quand je dois écrire des tests unitaires, si je n'ai pas copilote qui me mâche la moitié du travail, j'ai la flemme de faire mes tests unitaires. Je les ferai plus tard. Je me dis toujours le fameux plus tard.

Bruno:
On verra demain.

Anthony:
On verra demain. Pour l'Anthony de demain, il sera peut-être plus motivé.

Lucie:
Il aura grave envie de le faire.

Anthony:
Il aura bu plus de café. Alors que quand j'ai un copilote qui me génère le squelette de mes tests unitaires, j'ai moins à taper, je me concentre sur ce qui m'intéresse. Et là, je l'ai fait. donc c'est des tout au début quand Copilot a commencé à sortir maintenant ça fait quoi ça fait 4 ans je pense et qu'il y a eu ChatGPT puis les grosses annonces Microsoft Copilot 365 et tout le mot qu'ils ont utilisé à chaque fois c'était corvée et en fait, les tests unitaires pour beaucoup c'est une corvée, implémenter, rework etc c'est des corvées donc on veut pas faire les corvées donc on délègue les corvées soit à des stagiaires soit à des IA et puis après nous on prend les parties qui nous intéressent.

Bruno:
Je rigole pour les stagiaires pour tous les stagiaires qui nous en foutent vous parliez de cette approche du rework parce que ça te supprime effectivement une bonne partie de rework et effectivement on est preneur de ce genre de choses, je serais curieux aussi quand même de regarder le travail que ça nécessite la mise en place de ces outils là donc on a parlé un peu du changement côté designer, déjà à quel point Est-ce qu'il y a de la friction côté designer sur la mise en place de ces systèmes-là ? Et après côté aussi développeur, est-ce qu'il y a des frictions sur le fait de voir arriver un figma dans ton VS Code ? Est-ce qu'il y a des points de friction quand même à certains moments ?

Lucie:
Je pense qu'il y a peut-être des points de friction, mais ce qui est hyper important, c'est ce que tu disais, qui était la vision de notre CTO depuis le départ, qui est de dire pas de changement d'environnement. En fait, le développeur ne veut pas aller dans Figma. Il n'y a pas de raison que nous, en tant que Figma, on veuille que le développeur vienne. Et le designer est peut-être content, finalement, que le développeur ne vienne pas dans Figma. Du coup je pense qu'effectivement oui à la collab avec des, lanes ou vraiment des routes extrêmement claires pour chacun et c'est ce que les gens ont du mal à comprendre au début donc t'as raison il y a une friction qui est une question mais en fait ça veut dire quoi ? C'est à dire que les développeurs vont venir qu'ils vont regarder un peu plus tôt, et c'est pour ça que dans le dev mode au delà de la partie connectivité de la partie effectivement il y a un plugin dans Viascode etc, il y a toute une partie workflow en fait il faut se mettre d'accord et c'est la raison numéro 1 qu'on entend pour ne pas mettre en place du dev mode pourquoi je ne le ferai pas, et parce que en fait c'est pas une question d'outil c'est une question de changement c'est une question de workflow, c'est une question de revoir nos process, process qui souvent d'ailleurs n'existe pas vraiment, qu'on a jamais formalisé. Voilà, prends ça super, et donc dire il va falloir s'asseoir, il va falloir se mettre d'accord il va falloir définir le process et puis derrière seulement on l'outillera, c'est du changement, donc effectivement ça crée une friction qui est je dirais même pas liée à l'outil, qui est liée simplement au fait qu'il va falloir s'asseoir et définir un truc, dans lequel on a un petit peu navigué à vue jusqu'à maintenant, mais c'est là que et c'est pour ça qu'on a eu pas mal de projets notamment il y a deux ans mais encore aujourd'hui, où on discute avec, notamment OnePoint par exemple pour tel client comment est-ce qu'on peut l'aider à passer au-dessus de la partie workflow, de la partie changement. Et ça c'est parce que l'outil, c'est un outil j'ai envie de te dire, une fois que t'as expliqué comment ça marche, ça marche. Mais c'est beaucoup plus voilà, voilà comment on va le faire et puis voilà à quoi va ressembler le bon process et voilà pourquoi tout le monde y gagne. Et ça c'est l'accompagnement du changement et ça prend du temps.

Bruno:
Alors c'est peut-être parce qu'on est sur le podcast If Design Dev, où du coup on choisit un angle d'attaque, mais moi de ce que je perçois quand même dans tout ce qu'on a évoqué jusque-là, c'est que c'est une volonté de Figma, ou en tout cas de ces outils-là, de faciliter la vie du développeur et des développeuses. Est-ce qu'il n'y a pas du coup côté design des gens qui disent « Mais pourquoi est-ce que moi, je devrais faciliter la vie des autres ? » « Il faut qu'on me facilite ma vie à moi aussi en fait.

Lucie:
» Alors on développe plein de choses tous les jours pour faciliter la vie des designers. Il y a plein de choses qu'on fait qui sont pas forcément liées à DevMode, il se trouve que là aujourd'hui on parle de ça, mais il y a plein de trucs qu'on fait aussi pour les designers, j'espère qu'ils le savent, et ça reste, alors par contre oui on est là pour améliorer la vie des dev, on garde une conviction qui est qu'on vient du design et que on parlait d'AI tout à l'heure dans un monde où il va y avoir beaucoup de contenu et beaucoup de sites beaucoup de produits digitaux qui vont quasiment être construits tout seuls et d'une qualité assez médiocre par les IA demain, le rôle du designer le rôle vraiment de construire des expériences utilisateurs, delightful comme on dit en anglais, c'est hyper important et donc le rôle du designer là-dedans il est hyper important, on va pas arriver dans un monde demain, et ça c'est une conviction Figma, où finalement il n'y aura plus que des devs parce qu'on pourra faire des espèces de design généré par l'intelligence artificielle. D'ailleurs, il peut faire le code pendant qu'ils y sont, puis il n'y aura plus personne. Non, on pense vraiment que pour faire une expérience exceptionnelle qui vous différenciera demain de tout le contenu généré par de l'IA et qui fera que vous aurez un produit meilleur, c'est des très bons designers qui parlent très bien avec les développeurs. Et ça, ça reste notre conviction. Donc, je pense que les designers n'ont pas à s'inquiéter.

Anthony:
Tu parlais des frictions. Dans les frictions, typiquement, avant que DevMod soit lancé en 2023, on avait tous la même interface donc on avait tous nos habitudes d'aller inspecter les trucs à tel endroit d'aller exporter nos fichiers d'une certaine façon et d'un seul coup tout a changé donc changement d'interface, il a fallu s'adapter aussi côté Dev parce que même si c'était dédié pour nous tout avait changé de place donc les gens qui avaient l'habitude d'utiliser Afigma bam, cassurent, donc heureusement qu'on avait pu l'anticiper en testant ça un petit peu en avance de phase. Et effectivement, au départ, tout était au même endroit. Aujourd'hui, on voit bien les deux phases, donc la phase conception, la phase développement et les workflows dont parlait Lucie. Ce qui est intéressant, c'est, Aujourd'hui, on peut marquer les choses comme prête. Donc on se dit, je travaille dessus que quand c'est prêt. Et un truc qu'ils ont rajouté avec le dev mode qui n'était pas avant, c'est comparer entre deux versions les différences. Et ça, qualité de vie incroyable. Parce qu'avant, c'était, attends, j'ai changé ce truc-là. La taille de la police, ce n'est plus la même. J'ai déplacé ci, j'ai déplacé ça. Et on n'avait aucun historique sur les fichiers. Donc l'historique, c'était quoi ? C'était, je copiais-coller, puis je mettais hold, machin et puis j'avais les deux côte à côte aujourd'hui on a la capacité de faire la comparaison entre deux versions. Donc les frictions ont été réduites au fur et à mesure c'était pas dispo dès le début mais on voit qu'ils ont écouté aussi les feedbacks des utilisateurs et en fait ce qui est intéressant, à plusieurs échelles c'est que Figma eux, ils ont des techs chez eux puisqu'ils développent, donc ils ont des techs qui peuvent parler à des techs ils ont des techs parler à des techs et qui nous écoutent. Il y a beaucoup d'entreprises, comme parlait Lucie, qui sont des grands comptes qui, eux, ont leur design système et qui vont avoir un figma et puis ils vont utiliser ça un peu de manière cadrée. Nous, comme on est dans le conseil, on voit plein de clients avec des niveaux de maturité différents. Et donc, c'est ça aussi qui nous a aidés à mettre un peu en place des méthodes et des pratiques pour justement réduire la friction. Donc, notre objectif, c'est la vitesse, c'est la qualité et c'est réduire les frictions au maximum. Et donc on accompagne nos clients dans l'usage de Figma, on accompagne les clients dans l'usage des IDE, etc. Pour faire en sorte que tout se passe le plus sereinement possible.

Bruno:
Il y a une idée qui me vient en tête en écoutant cette conversation, parce que j'évoquais tout à l'heure la tendance ASCODE qu'on voit partout. Là, effectivement, on applique aussi cette méthodologie au monde du design. Tu nous as parlé maintenant du concept de versionning. Au final, quand on peut avoir ce côté ready sur un design, sur Figma, c'est un peu comme quand on fait un push en prod. C'est une façon de comiter son travail. Est-ce qu'au final, toutes ces tendances, que ce soit aussi bien sur le design aujourd'hui au travers de Figma mais au travers d'autres métiers est-ce que c'est pas une façon de le monde reconnait enfin que le way of life des développeurs et développeuses est en fait le meilleur way of life parce qu'on a.

Anthony:
De la méthode, on est carré et on a des roufles en place et des choses qui marchent. Dans le monde du dev moi j'ai beaucoup collaboré aussi par exemple avec des gens qui font de la data, qui n'ont pas forcément les mêmes méthodes et il faut les amener avec, notre way of life parce que pareil, j'ai déjà vu des devs qui pouvoir partir en prod, il faisait contre H, dev, remplacer dev par prod, et puis il remplaçait partout, tu vois, dans un terraform, mais je suis là, je ne veux pas. Donc ouais, c'est effectivement, le software engineering, c'est pas une discipline scientifique, c'est pas ceci, mais c'est un tas de méthodes et un tas d'outils. Effectivement, on a parlé de Figma, on a parlé de langage, enfin demain, un site web qui est codé en TypeScript un site web qui est codé en Clojure un site web qui est codé en ce qu'on veut c'est juste un langage qui va traduire un besoin en un résultat ce qui compte c'est le résultat peu importe comment on le fait, chacun a adapté à son truc mais on a des méthodes pour faire ça de manière efficace et du coup on est enfin reconnu.

Bruno:
Sur les frictions on a parlé des frictions côté designer chez les devs il y a quand même une tendance à être un petit peu frileux sur ce côté les wheezy wig ces fameux outils qui génèrent du code, automatiquement depuis ce qui est fait par des gens qui ne sont pas développeurs ou développeuses, est-ce qu'il y a eu de la friction aussi sur la création de ces outils là et la mise en place de ces outils là côté dev ?

Lucie:
Les clients peuvent utiliser les outils de façon différente on peut générer du code on a beaucoup de clients notamment assez matures qui disent j'ai pas besoin qu'on me génère du code pour mes composants En fait, mes composants, ils sont dans mon GitHub, j'ai absolument tout. Par contre, on a besoin de faire le lien. Et donc ça, c'est un outil qu'on a qui s'appelle Code Connect, parce qu'en fait, on s'est rendu compte, la première version de DevMode, on générait du code. Et assez vite, les clients nous ont dit, en fait, on n'a pas vraiment besoin que Figma nous génère du code. In a vacuum. Et du coup, on a dit, ok, du coup, on va aller plutôt se faire parler les environnements. Là aussi, c'est de la collab. Et donc, CodeConnect, c'est la solution à ça. C'est de dire, on va aller chercher votre vérité et là où vous en êtes. Après, on a des tout petits clients qui disent, moi, ça m'intéresse un peu de génération de code parce que moi, j'en suis au tout début et finalement, ça met un pied à l'étrier. Ça ne veut pas dire que je vais prendre ce que me donne Figma comme parole d'évangile. Mais, en revanche, ça fait un un starting point et là ça permet d'aller plus vite donc pour nos gros clients t'as raison, on va pas aller générer du code pour des gens qui ont déjà des librairies colossales et qui.

Bruno:
Ont déjà des façons de travailler colossales Est-ce qu'avec le code connect du coup ça te met à jour ton Figma pour que ton Figma corresponde à ce qui existe ?

Lucie:
Alors ça peut se parler dans les deux sens et là aussi c'est vraiment là que c'est hyper important de prendre le temps de définir comment toi tu veux travailler, parce qu'il n'y a pas une seule façon de faire l'outil il est finalement relativement flexible, il faut voir toi à ton niveau de maturité ce que tu as envie de faire tu veux que ça se parle dans un sens, dans les deux sens, où est la vérité finalement souvent on considère que la vérité, en tout cas les développeurs considèrent que la vérité est dans GitHub oui j'ai des sourires tout à fait, ce qu'on comprend très bien parce qu'à la fin le produit final il quand même il vient de là, et puis on a quand même beaucoup de questions et notamment de nos clients qui ont une certaine dette technologique c'est qu'en fait le but de tout ça c'est quand même de certes sortir des produits de plus en plus vite mais qu'il y a une cohérence dans tout ça donc il y a un énorme avantage à bien prendre les composants qui sont dans GitHub et pas aller faire un peu n'importe quoi partout, voilà, donc il y a plein de façons de faire, l'outil a été pensé pour correspondre au niveau de maturité des différents clients et des différentes étapes des sensibilités, après, il y a effectivement une vraie étape de réflexion et de se dire comment on bosse ensemble. C'est pas, ah bah super, on va mettre ça en place et ça va régler tous nos problèmes.

Anthony:
Au niveau de code connect, nous, effectivement, on n'utilise pas forcément toujours le code généré, sachant que les langages qui sont générés sont assez restreints aussi. Dès qu'on va commencer à faire du web, on ne va pas avoir forcément les composants React, sauf à utiliser des plugins, des trucs comme ça.

Lucie:
Avec du CSS. Par contre, le truc, c'est que Figma est une boîte qui est en permanence. Donc du coup, ton information a quelques semaines de retard.

Anthony:
Mais il y a pas tout et de toute façon on aime bien quand même nous taper nos lignes de code mais en fait Storybook c'est un peu ce qu'on avait l'habitude de mettre en place avant avec, Storybook qui était un outil qui permettait de faire. Le lien et la présentation de nos composants en mode vous pouvez tester les composants directement voir les variantes, voir à quoi ça ressemble une fois que ça a assemblé etc et permettre de faire de la recette par exemple aujourd'hui avec CodeConnect on est obligé d'écrire du code pour connecter donc on écrit notre composant à côté on écrit le petit fichier FigmaConnect qui en fait récupère directement, avec la ligne de commande les propriétés du composant et on fait le lien entre les deux on fait en fait l'usage on va écrire l'usage du composant, et ensuite on le pousse vers Figma donc c'est d'abord on tire depuis Figma les propriétés donc ça va nous faire un petit JSON avec toutes les propriétés que je peux renseigner, mes variantes, mes couleurs, mes machins. Et après, on push une fois qu'on a fini. Et après, ce que ça fait, c'est que dans Figma, je peux directement tester les composants. Donc, ce que je faisais avant dans Storybook, maintenant, je le fais dans Figma. Donc, d'un côté, j'ai le design et en fait, juste à côté, j'ai toutes mes variantes que je peux tester et surtout, le bout de code que je peux réutiliser pour l'intégration dans mon appli. Donc, en fait, c'est pas je vais générer le code du bouton, mais je vais générer le code d'utilisation du bouton avec telle variante ou telle autre variante. Donc ça c'est assez pratique pour que tout le monde utilise les choses de la même façon. Parce que je me dis bah tiens, quand mon form est disabled, comment est-ce que je le passe en mode disabled ? Je vais dans Figma, je switch, je mets variantes disabled, et je vois en fait c'est la propriété disabled que j'ai rajouté à tel endroit. On va avoir toutes ces variantes qu'on peut enseigner, mais pour ça, il faut encore écrire le code. C'est le développeur qui va écrire le code et qui va le push pour faire le lien.

Lucie:
Et ça, typiquement, c'est un endroit où l'EI pourrait être super intéressant. Typiquement, dans les choses qu'on regarde, c'est comment est-ce que cette partie-là, qui reste effectivement relativement manuelle, entre guillemets, pourrait éventuellement être automatisée. Mais ça, c'est le futur.

Bruno:
Après, c'est un futur qui tend à arriver de plus vite qu'on pense à chaque fois. Ça va assez vite. Donc au final, il y avait effectivement une question sur la qualité du code généré. Donc en fait, ce que tu dis, c'est que dans l'usage, ce n'est pas tant que ça le code qu'on va générer automatiquement. C'est juste cette connexion entre ton code et le Figma qui permet en fait une fluidité sur le long terme.

Anthony:
Chez nous, avec notre niveau de maturité, c'est plus comme ça qu'on l'utilise. Et on en parlait aussi, on met en place un design system. En fait, la documentation de comment j'utilise mon design system, elle est directement dans Figma puisque j'ai connecté mon code et je sais que, je clique sur le enfin mon bouton je l'importe depuis tel package et j'ai toutes ces variantes qui sont disponibles donc c'était quelque chose qu'on faisait à côté avant en utilisant par exemple Storybook maintenant on rapatrie ça directement dans Figma parce qu'en plus dans mon IDE j'ai aussi accès, tout est centralisé donc ça devient la source de vérité, du design du produit donc même si le code à la fin c'est ça qui tourne sur la WKN et c'est ça qui va s'exécuter en poussant le code dans Figma on a une vue d'ensemble qui est hyper intéressante.

Lucie:
Après, si vous êtes une entreprise beaucoup moins mature, on a aussi, typiquement, on a un design système en marque blanche qui a son code connect et qui a le code qui va avec. Donc, tu peux partir pas d'une page blanche, tu peux partir d'un design système embryonnaire existant sur lequel tu vas rajouter tes couleurs, tes fontes, toutes tes variables, etc. Mais qui a déjà une base, un squelette de code que tu vas pouvoir récupérer et faire vivre avec le code connect. mais ça c'est je dirais l'autre côté de maturité, on est sur des cas d'usage complètement différents mais tu gagnes du temps.

Anthony:
Et dans ce qu'on a parlé niveau qualité du code aussi il y a tout ce qui est accessibilité qui est hyper important et ça ça se traduit dans le code le fait de rendre ces composants accessibles etc on le voit pas forcément directement dans Figma donc ça c'est plutôt dans le code qu'on va mettre en place les outils pour vérifier que nos composants sont bien, bien implémentés Pas mal.

Bruno:
Alors ça c'est effectivement un sujet important qui est pas souvent pris en compte donc c'est cool de savoir que c'est géré aussi de manière automatique mais du coup moi ce qui me fait poser la question est-ce que le code est rendu accessible aussi parce qu'on parle beaucoup d'accessibilité du produit qu'on génère mais assez peu du code qui doit lui aussi être accessible parce qu'on a aussi des développeurs et développeuses qui sont en situation de handicap mais ça je sais pas si c'est un.

Anthony:
En tout cas chez nous on a des développeurs en situation de handicap et c'est des développeurs comme tout le monde donc on fait en sorte que qu'il n'y ait pas de différence entre les gens. Donc, effectivement, ce que je disais juste avant, le fait d'avoir la documentation qui remonte dans Figma, ça nous force à écrire cette documentation et ça nous force à la toucher. Donc, forcément, derrière, les gens qui vont vouloir l'utiliser, ça va être plus simple aussi. Je n'ai pas envie d'anticiper ta question de la fin, mais ma réponse sera dans le sens de l'accessibilité. C'est qu'on va utiliser des tabulations parce que si la personne a des problèmes de vision, elle va vouloir ajuster ces trucs comme ça. Donc ça, ça fait partie des pratiques que les devs essayent d'infuser dans le monde entier, c'est que les machines, les outils de travail s'adaptent au handicap, donc pour nous il n'y a pas de différence entre un développeur qui a un handicap et un autre développeur.

Bruno:
Vous parliez aussi tout à l'heure des technos dans lesquels le code est écrit. Aujourd'hui, en fait, c'est majoritairement du React ou on peut utiliser même du Vue ou du Ruby si on a envie ?

Lucie:
Honnêtement, je n'ai pas toute la liste. Mais Vue, oui. React, oui. Et Ruby, je ne sais pas.

Anthony:
Après, nous, on a plus tendance à utiliser, par exemple, le code CSS que j'ai généré, et puis à l'adapter. Le truc, c'est que Figma, c'est un diagnostic déjà de base du langage. Effectivement, il y a quelques accélérateurs pour la génération de code. Ça fait aussi des applis mobiles. Donc, on peut générer du Swift, on peut générer du Kotlin, je crois. Je ne sais plus. Mais je vous avoue que ce n'est pas celui que j'utilise le plus. J'aime toujours, moi, faire mon petit truc.

Bruno:
On a aussi nos petites lubies côté Dev. On choisit une manière de développer, un ensemble de nomenclatures. À quel point est-ce qu'on peut guider Figma dans le respect de ces nomenclatures ?

Anthony:
C'est quand on discute avec les designers c'est.

Lucie:
Pas Figma qu'il faut pousser c'est ton designer.

Anthony:
C'est le designer et donc nous à notre échelle on fait ça avec nos équipes de design, c'est aussi le croisement des expériences et puis c'est quelques événements où on partage ces bonnes pratiques mais, on l'a dit tout à l'heure les développeurs sont des divages, on peut pas avoir un framework qui va marcher avec tous les développeurs, enfin c'est utopique et surtout on en voudrait pas, chacun a son idée, chacun son truc etc donc ce qui est important c'est l'équipe qui délivre la valeur, il faut qu'elle soit d'accord, donc c'est pour ça que typiquement moi quand je commence un projet, je pars pas en disant bon bah on fait des sprints de deux semaines on fait un mono repo on fait ceci, on fait cela, c'est attends je monte mon équipe, ok on se pose la question combien de temps font nos sprints, est-ce qu'on met en place un mono repo ou pas on va utiliser quel outil pour la CI tous ces trucs là, il faut que l'équipe s'en empare et dans l'équipe il y a les designers, donc c'est à ce moment là qu'on va dire ok, nous on a besoin que ça soit architecturé comme ça on a besoin que vous utilisez les variables on a besoin que ceci, cela et après on déroule.

Bruno:
De la même manière que les designers, eux, vont pouvoir dire nous, on travaille comme ça, on a besoin de ça, ce genre de choses.

Anthony:
On va se challenger. En fait, on va s'enrichir l'un l'autre. C'est ça qui est aussi intéressant dans la collaboration. C'est pour ça qu'on aime ça. C'est qu'il y a toujours à apprendre de n'importe qui. Donc, beaucoup d'humilité. Il faut beaucoup d'humilité pour faire du dev. Effectivement, des fois, on va créer des boutons. On va créer des boutons en React. On l'a fait mille fois. Mais il y a besoin de faire des boutons. Je vais faire mon bouton tranquille. Après, je ferai des trucs plus intéressants.

Bruno:
Ça fait partie du job. dans cette, mise en parallèle effectivement des façons de faire il y a je pense aussi une, attends j'essaie de voir comment je peux former ma question parce que tu as évoqué tout à l'heure, la complexité du métier de dev front versus dev back pardon, moi je l'ai dit plusieurs fois à ce micro le dev front est un métier qui est devenu extrêmement complexe par rapport à ce que c'était il y a quelques années, il y a quelques années c'était juste un métier d'intégrateur c'était effectivement traduire un fichier PSD en HTML aujourd'hui il y a une vraie complexité au final des outils comme ce que vous faites chez Figma étaient un peu une nécessité, parce qu'avec toute cette complexité qui est portée côté code dans le front, il y avait une nécessité en fait aussi de streamliner tu parles beaucoup de workflow de rapprocher tout ça.

Lucie:
En tout cas c'est ce qui s'est passé.

Anthony:
C'est vrai que le front a tendance à se complexifier on pense beaucoup en plus à l'application web mais le front ça peut être autre chose Vachement plus complexe.

Lucie:
En fait nous on voit chez nos clients des choses incroyables, quand tu penses à ce que peut développer un Airbus, tu imagines ton cockpit bon, là on n'est plus sur une appli qui peut être pas très agréable à utiliser, on est vraiment sur des choses très complexes en termes de produits digitaux et là c'est la société entière qui change, quasiment tout devient digital, on a beaucoup de conversations avec nos clients sur le lien aussi entre le hardware et le software et les expériences multimodales. Effectivement, ça devient très complexe.

Anthony:
Et j'aime bien ce retour aux boutons où on avait des interfaces, tout était digital, il n'y avait plus de boutons et maintenant on a tendance à remettre des boutons aussi parce qu'on se rend compte que les interfaces c'est sympa mais c'est intéressant d'avoir des petits trucs à tourner ou à appuyer aussi. Parce que c'est vrai qu'on voit les voitures où il n'y a plus rien, c'est juste une tablette, Un petit retour en arrière.

Bruno:
Mais l'avantage, le problème du bouton, c'est qu'il est physique et que tu ne peux pas le changer après coup. Si jamais tu veux le changer. C'était le grand argument de Steve Jobs sur la sortie de son iPhone. On a une question dans le chat qui demande si CodeConnect sera aussi ouvert à la suite de plugins. Qu'est-ce qui est aussi l'une des forces de Figma ?

Lucie:
Je ne sais pas. Je ne sais pas.

Anthony:
Pour utiliser les plugins et l'API Figma, il faut avoir le plan Enterprise. C'est déjà le petit...

Lucie:
T'as deux choses, t'as les plugins privés et les plugins privés tu fais beaucoup de choses et t'as les plugins publics qui sont pas tout à fait la même chose et pour les plugins privés effectivement il faut les plans interprès.

Anthony:
Ouais donc CodeConnect il est dispo, il est gratuit en CLI donc j'ai pas testé la toute dernière version c'est parce que ça évolue aussi mais il est dispo, on l'installe dans son CLI on génère nos fichiers Figma etc, après dès qu'on va vouloir utiliser les plugins, ça c'est plutôt les designers souvent qui ont tendance à utiliser des plugins pour pré-générer, certains designs pour générer des fiches d'informations des écrans, des trucs comme ça. Pareil pour encore nous prémacher le travail et dès qu'on veut faire les plugins privés utiliser l'API Figma qui est très versatile. C'est là où il y a un plan enterprise à avoir donc c'est pas ouvert encore à tout le monde.

Bruno:
Pour terminer j'aurais une question un peu double. La première c'est que entre ce que vous faites aujourd'hui avec ce DevMod et CodeConnect et tous les outils d'IA on a parlé de copilot et autres aujourd'hui, Il y a une tendance à voir le métier de codeur disparaître de plus en plus. Les choses se font de manière de plus en plus seule. Donc, le premier point de ma question, c'est est-ce que vous pensez qu'il y a effectivement une tendance affirmée et qui va aller de plus en plus loin sur la disparition de ce métier-là spécifiquement ? Et ma question dans un deuxième temps, ce serait, c'est quoi aussi l'impact de ces outils d'IA dans le monde des designers ? Je ne sais pas si Figma, vous avez des choses qui vont générer automatiquement. J'ai cru comprendre que oui il y a des trucs d'auto-layout et compagnie mais à quel point est-ce que ces technos changent aussi d'autres métiers j'en profite d'avoir quelqu'un qui fait un autre métier ici parce que c'est toujours intéressant.

Lucie:
Alors fun fact, moi j'ai fait mes études en comptabilité il y a 20 ans, et ça fait longtemps qu'on dit le comptable va disparaître, le comptable aurait d'ailleurs déjà dû disparaître parce que le premier qui a été automatisé dans tout ça c'est le comptable passé à une écriture comptable je vous rassure il n'y a pas de chômage chez les comptables c'est l'une des professions de France d'ailleurs si vous changez, c'est l'une des professions de France où il n'y a pas de chômage, parce qu'en fait le métier change effectivement à la partie la plus basse passer à une écriture simplissime ça disparaît, en revanche, la comptabilité comme le code comme le design, en fait c'est des matières complexes, donc moi je ne crois pas du tout que les gens vont, disparaître, je pense que ce que tu disais tout à l'heure sur l'intelligence artificielle est tout à fait vrai, on va avoir des automatismes, on va avoir de l'intelligence artificielle, encore faut-il être capable de lire de comprendre le code qui a été sorti d'avoir un point de vue et de le changer si nécessaire et tout ça, ça nécessite encore des humains alors peut-être pas pour toujours mais bon je pense qu'encore un certain temps, et ça demande des humains qui ont quand même bien réfléchi qui ont tout compris derrière c'est pas simplement des humains qui vont regarder des choses et puis dire rouge vert, rouge vert vraiment des humains qui comprennent toute la logique derrière qui disent oui ça a du sens dans le contexte dans lequel je suis que je ne pourrai jamais expliciter complètement ça a du sens ou ça n'en a pas. Donc là dessus je pense que pour les développeurs pas trop s'inquiéter, pour les designers même point de vue, effectivement nous on a des outils d'IA, on a par exemple des outils d'IA tu parlais tout à l'heure des frames qui renomment les frames pour éviter frame 1, frame 2, frame 3 donc cette IA là devrait faire plaisir à la fois aux développeurs et aux designers. L'IA va te permettre de faire toutes les tâches du genre renommer les frames, ça n'intéresse pas le designer donc ça c'est très bien, ça va te permettre aussi d'itérer et de te poser des questions donc là c'est de l'IA générative de la même façon que tu peux générer un texte tu peux générer dans Figma aujourd'hui des designs, il n'empêche qu'il va falloir itérer il va falloir se poser des questions, il va falloir changer et surtout si on ne veut pas que tout se ressemble ce qui est quand même le gros risque si on ne veut pas que tout se ressemble il va falloir rajouter la patte du designer, et celle-là à nouveau c'est pas l'IA qui va le faire, Donc, nous, on a ce point de vue-là. Et puis, l'autre point de vue, et là, on se travaille beaucoup là-dessus en ce moment chez Figma, c'est OK, maintenant, avec l'IA, qu'est-ce qu'on peut faire qu'on n'a jamais fait ? En fait, qu'est-ce qu'on peut aller faire dans Figma en termes de motion design, en termes d'expérience absolument incroyable, expérience qui n'existe pas aujourd'hui sur le web ? Parce qu'aujourd'hui, nos expériences, elles sont assez basiques. Quand tu regardes les applis, surtout en Europe, on a simplifié à mort tout, tout est en noir et blanc, et puis voilà. Est-ce qu'on peut faire des choses complètement incroyables, est-ce qu'on pourra faire demain des expériences qu'aujourd'hui on n'imagine même pas parce que les outils s'améliorent énormément et ça c'est le côté très cool du futur.

Anthony:
Pour répondre à la question sur le métier, moi je pense qu'entre les années 90 et aujourd'hui il a déjà changé, donc aujourd'hui on parle beaucoup d'ingénierie logicielle, des choses comme ça, à l'époque on parlait de programmeurs parce que ils avaient des specs détaillés, des specs techniques détaillés et en fait ils traduisaient la spec technique détaillée en ligne de code et on ne leur demandait pas de réfléchir. On avait des cycles en V, on avait des choses comme ça et tout était très basique. Il y avait déjà des mouvements qui avaient commencé pour rendre ça un peu plus intellectuel. Avec l'agilité aujourd'hui, les specs ont tendance à être beaucoup plus vivantes et donc à venir un peu plus tard, etc. Et on demande aux développeurs, parce qu'on n'est plus sur des programmeurs, on est sur des développeurs ou des ingénieurs logiciels, de réfléchir. C'est pour ça qu'on les inclut aussi dès le début dans la conception et tout. Donc en fait, le travail a déjà évolué entre il y a 20 ans et aujourd'hui. Ce n'est plus du tout le même. Et effectivement, les personnes qui restent des programmeurs, ont plus de mal à trouver leur place dans le marché aujourd'hui. Mais il y a quand même une énorme majorité des développeurs qui font ça comme travail alimentaire. Et ça marche très bien. Il n'y a pas de sujet. Chacun a son truc. C'est plus les développeurs passionnés qui vont devenir les développeurs augmentés, de demain avec l'IA, avec tout ça. Et en fait, encore une fois, nous, notre rôle, c'est de résoudre des besoins. J'ai un problème, je trouve une solution. Le code, c'est un moyen de résoudre ce problème. Et moi, je suis hyper content quand je résoudre un problème sans code. Encore une fois, si on parlait de no code, si j'ai une solution no code, si je mets une ligne dans un Excel, ça m'envoie un email, etc., mais je le fais. Parce que j'ai résolu le problème de mon client. Je passe à autre chose. Et donc, moi, j'ai besoin de résoudre des problèmes, de confronter comme ça des problèmes de logique intellectuelle et de trouver des solutions. C'est trouver des solutions. Ce qui est enrichissant, c'est que j'ai apporté une solution. C'est pour ça que quand je reviens dessus, ça me saoule. Je n'ai pas envie de le refaire. Et donc, le métier de programmeur est devenu le métier de développeur. Demain, développeur augmenté. Mais il y aura de la place encore pour tout le monde.

Bruno:
Pour rebondir sur vos deux propos, déjà sur l'histoire des specs, ça fait aussi partie des exemples pour montrer que l'IA ne va pas nous remplacer. Parce qu'il y a des années, on faisait des specs qui étaient hyper détaillés. Et ça n'empêche qu'on arrivait quand même à sortir des applications qui ne correspondaient pas à ce qui était justement demandé. Donc ça montre que même si tu fais des specs hyper détaillés à l'IA, tu n'auras pas forcément produit si bien que ça. Et pour revenir aussi, Lucie, sur ce que tu dis, sur le risque de l'uniformisation, on l'a connu aussi il y a quelques années avec Bootstrap qui était un super produit qui permettait de faire des frontes, techniquement de manière hyper simple et puis en fait petit à petit on a vu tous les sites qui se ressemblaient parce que tout le monde utilisait Bootstrap et en fait c'est vrai qu'il y avait une espèce d'homogénéité mais si vous pouviez le customiser un peu, le changer, on reconnaissait assez vite la patte du truc donc j'imagine qu'avec l'IA c'est les mêmes sujets en fait c'est que si on prend tous les mêmes outils on aura tous les mêmes choses à la fin.

Lucie:
Surtout il se nourrit du contenu ça va être incroyable, plus il va manger la même chose plus la soupe va être parfaitement lisse c'est le risque de lire écoutez top.

Bruno:
Merci beaucoup à vous deux pour cet épisode pour terminer j'aurais deux questions rituelles, la première étant est-ce qu'il y a un contenu que vous souhaiteriez conseiller à nos auditoristes.

Anthony:
À la croisée du dev et du design un petit peu c'est GameUI Database c'est un site qui recense toutes les interfaces graphiques de tous les jeux vidéo, qu'ils ont sorti une version 2.0 cette année qui est incroyable. Donc c'est un mec qui taffe dessus un peu tout seul, et la communauté peut l'enrichir. Et en gros vous prenez n'importe quel jeu, vous allez dessus, ils ont pris des screens, des menus, des trucs in-game, des dialogues et tout, ils ont un moteur de recherche qui est incroyable. Et donc ça quand on veut s'inspirer c'est vraiment dingue. Vraiment une pépite de ressources à croiser du dev et du design.

Lucie:
Trop bien. Moi je pense, parce que c'est presque Noël, à un livre qui s'appelle Les marins ne savent pas nager. Parce que pour moi c'est le livre que Lya n'aurait jamais pu écrire. En fait elle l'enga, c'est un monde imaginaire qui se passe à peu près au 18ème siècle, sur une île loin de tout. Et elle invente un langage propre, une société propre, mais qui est très proche de ce qu'on imagine de l'époque et en même temps c'est complètement inventé c'est un très beau livre et moi j'aime beaucoup l'idée que le cerveau humain est absolument incroyable et c'est écrit par une québécoise et on lit pas beaucoup et du coup je me disais est-ce que c'est du québécois ? Est-ce que c'est du québécois du 18ème siècle ? et en fait non pas du tout, c'est quelque chose qu'elle a complètement inventé donc l'idée d'inventer des langages et vraiment de montrer la richesse humaine c'est merveilleux.

Bruno:
Je vous le conseille alors pour avoir l'épisode très diffusé après Noël.

Lucie:
C'est pas grave. Même après Noël, on est en train de se faire plaisir.

Bruno:
On mettra bien évidemment les liens en description. Et pour terminer, la question rituelle du podcast, est-ce que vous êtes plutôt espace ou tabulation ? On va commencer par Lucie.

Lucie:
Alors moi, je vais dire espace parce que vous ne le voyez peut-être pas, mais sur l'avant-bras gauche de Bruno, qu'est-ce qu'on voit ? On voit des planètes. Le système solaire, j'imagine, de ce que j'en vois. Et en fait, j'avoue, quand tu m'as posé la question je l'ai vue et donc la réponse est devenue assez naturelle et par ailleurs je ne suis pas développeur donc je n'ai pas d'avis sur la question que j'imaginais technique, espace ou tabulation donc je vais partir sur la version design et beauté espace.

Bruno:
Très bien, et Anthony ?

Anthony:
J'ai répondu tout à l'heure mais tabulation pour des questions d'accessibilité effectivement laisser la personne configurer son idée comme elle veut et surtout configurer vos linter vos bonnes pratiques de code automatiser tout ça, ça sert à rien, de réinventer la roue etc Vous mettez en place les règles dès le début en consensus avec l'équipe et mettez des tabulations.

Bruno:
Canon. Merci beaucoup Lucie. Merci pour l'accueil. Merci à tous d'avoir écouté cet épisode. J'espère qu'on vous a donné envie d'utiliser Figma, d'utiliser ce dev mode sur Figma et de vous faciliter la vie et d'accepter un peu plus de code générés dans votre code base. Mais comme j'espère que vous l'avez compris, ça vous permet de faciliter la vie de tout le monde, aussi bien côté designer que côté développeur ou développeuse. Et moi, comme toujours, je vous remercie de partager ce podcast autour de vous. Je vous souhaite encore à nouveau une très bonne année 2025, parce que c'est le dernier enregistrement de l'année 2024. Mais je sais qu'on va diffuser à peu près, je pense, fin janvier. Enfin bref. Je vous remercie beaucoup. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.