Rentrons dans le vif du sujet. Ça fait deux ans quasiment maintenant que j'ai la chance d'interagir via mon travail avec Figma, avec des équipes design un peu partout en Europe, et je vois des patterns se dessiner quant aux problématiques et aux questions qui reviennent régulièrement. Et une des choses que j'ai observées, c'est qu'au fur et à mesure que Figma embarque dans l'expérience d'édition design créative, des logiques qui se rapprochent des logiques de code front-end, notamment des logiques de web CSS parce qu'on est très web-first, outils dans le navigateur obligent, il y a un gap qui se crée dans les designers, entre ceux qui arrivent naturellement à se faire à ce modèle mental assez facilement, parfois c'est parce qu'eux-mêmes ont un peu déjà codé dans le passé, ou alors juste qu'ils ont utilisé des outils historiquement comme Axure qui se rapprochaient beaucoup de ces modèles-là, versus les designers qui ont du mal justement à rapprocher leur modèle mental existant de ces modèles plus orientés techniques. Et typiquement, je vois ça quand on a des discussions autour de tout ce qui est auto-layout, flexbox et compagnie, tout ce qui va être variable.
Voilà, ça a été à nouveau un mini-choc pour certains designers qui ont du mal un peu à s'affaire à la gymnastique mentale. Moi, la première fois que j'ai eu des sujets design token à traiter, c'était dans mon ancienne équipe design. Et j'avoue que la première fois que j'étais confrontée à ça, j'étais mépaire.
Mais en même temps, le rapprochement entre les logiciels de création digitale et les logiques de code, en fait, elle est essentielle. Les outils en créa, on ne le sait pas trop, mais en fait, on est en retard. On est massivement en retard par rapport à ce que le code peut faire maintenant.
Et historiquement, on était un peu les créas dingues, on faisait des maquettes, puis les designers râlaient en disant ça va être trop dur à implémenter, qu'est-ce qu'ils nous ont fait ? Aujourd'hui, en fait, le code, il peut faire plein de trucs. Et c'est limite plutôt le problème inverse, on n'arrive pas à débloquer assez. Et en fait, il y a des attentes aussi des développeurs par rapport aux designers.
Alors, je voulais juste balancer quelques statistiques parce qu'on a un rapport qu'on a fait chez Figma. On a interviewé pas mal de développeurs pour prendre leur ressenti dans la collaboration par rapport aux designers. 80% des développeurs qui pensent que leur entreprise ferait profit d'une collaboration plus étroite entre designers et développeurs.
Et parmi ceux-là, il y a quelqu'un de 92, donc c'est énormissime, des développeurs qui aimeraient que les designers soient plus au fait des processus de développement, des logiques de développement, de comment ça marche, etc. Bref, on est nombreux, peut-être. dans la communauté design à avoir un peu de mal à se faire à ces logiques de code mais c'est essentiel de s'y faire et donc je pense que ça passe par un changement de perspective de la démystification de la pédagogie enfin voilà une approche assez didactique puis l'acquisition de bases qui vont nous permettre de comprendre en tout cas au moins de façon théorique comment c'est construit en fait et donc voilà donc je pensais à toi parce que donc déjà t'es un front-end on en a parlé mais t'as une forte sensibilité design de par ta formation ce que t'as passé par éthique qui est une formation qui, en tout cas à l'époque, était assez hybride, enfin, qui touchait un peu à tout.
Tu as cette perspective très worldwide, très internationale, sur les sujets web, via ta participation, enfin, ta connexion en tout cas avec les sujets des différentes communautés W3C. Et puis, tu as parlé aussi à Skima en 2022, accessoirement, sur ce sujet justement de standardisation des design tokens. Et c'était avant les variables.
Donc voilà, on va faire une session didactique aujourd'hui. En gros, j'ai un peu set the stage. On va essayer de mettre un peu à plat des choses autour du web et de la notion de standardisation du web pour les designers qui, comme moi, ne savent pas coder. Et on va essayer de faire en sorte que cette espèce d'entité un peu mystérieuse qu'on appelle web, qui fait un peu magie, parfois on se dit c'est le web, il y a des règles, on ne les connaît pas trop, mais voilà, ça marche, on laisse les développeurs gérer. On va essayer de lever un peu le voile sur ce qui se passe dans les coulisses de tout ça, comment c'est construit, comment c'est défini, et comment est-ce que toutes ces choses derrière qui se font derrière les coulisses, ça influe notre travail de produit et de designer et de développeur.
Donc voilà, première question que je voulais te poser. Quand tu es designer, j'ai l'impression que souvent, enfin moi c'était l'approche que j'en avais au tout début, la tech, les logiques de code, tout ça, tu as très l'impression que c'est très scientifique, très binaire, de oui ça marche, non ça ne marche pas. Oui ça passe le QA, non ça ne passe pas le QA. Et d'ailleurs, ça va peut-être être un héritage des autres disciplines design, de 3D, de print, etc., où on a souvent des contraintes physiques fortes et très claires dans ce qu'on peut faire.
Et du coup, je pense qu'on est nombreux à aborder le design digital et notamment le design dans le web en se disant, il y a des règles, elles doivent exister quelque part. Et du coup, quand on parle de standardiser le web, en fait, c'est quoi ? Est-ce qu'il n'y a pas déjà des règles qu'on devrait déjà suivre dans le web de base ?
C'est quoi ces standards ? Quand on parle du web... On essaye de garder le navigateur en tête. C'est-à-dire que la manière dont on consomme le web, c'est via un navigateur, peu importe que ce soit via un smartphone, un PC, n'importe quoi.
Les navigateurs sont des logiciels qui affichent des sites web. Et un site web, si on soulève le capot, ça va être des langages qui sont différents et qui fonctionnent d'une manière précise. Si on prend par exemple le HTML, j'aime bien expliquer le HTML comme étant là. On prend un site web comme un magasin, comme un bâtiment. Le HTML, c'est vraiment les fondations du bâtiment.
Le CSS, ça va être la taille des pièces, la couleur des murs, la disposition des meubles dans la pièce. Et puis le JavaScript, ça va être, si il y a un ascenseur et que je suis au troisième étage et que j'appuie sur je veux descendre peut-être que l'ascenseur fera autre chose avant parce qu'il y a d'autres personnes qui utilisent le bâtiment avec moi. Tout ça.
C'est des langages qui existent depuis la fin des années 90. Et donc, quand on utilise le navigateur web, les navigateurs, en fait, ils vont faire des choses avec le HTML, le CSS et le JavaScript qui ont été littéralement définis en amont. Donc, par exemple, quand j'utilise Google Chrome ou quand j'utilise Safari et que je suis en focus dans un champ de formulaire, je vais avoir éventuellement un focus ring autour de ce champ pour m'indiquer que je peux commencer à taper dedans et je suis un focus dedans. Sauf que ce focus ring pourrait être différent selon le navigateur ou un autre parce que ce sont des entreprises qui ont un branding différent, mais en attendant, le HTML et le CSS prennent en compte le fait que certains éléments doivent fonctionner de telle manière.
Et le fait que certains éléments fonctionnent d'une manière précise, C'est parce que ça a été défini et standardisé. Et quand ça a été standardisé, ça peut dire que Safari ou Google Chrome suivent le standard et disent, bon, effectivement, on va mettre un petit contour, comme ça, c'est facile à l'utilisateur. Ça, c'est vraiment un exemple, mais quand il y a des standards pour le HTML, il y a des standards pour le CSS, il y a des standards pour beaucoup de choses, en fait, qui sont invisibles à nous, consommateurs du web, dans la vie de tous les jours.
Quand on a des images et que c'est du PNG, le PNG, c'est plein de pixels. qui sont les seins de la suite des autres, eh bien le PNG, c'est un standard. Les fichiers SVG, c'est un standard aussi. Le JSON, qui est un format de données qui peut transiter entre un serveur et un autre, c'est standardisé aussi. Et en fait, la manière dont on a de consommer le web aujourd'hui, c'est tout simplement basé sur une suite de standards qui parfois héritent les uns des autres.
Et sans eux... Ça serait compliqué. Tu avais une très bonne métaphore quand on discutait du sujet en amont. que j'avais trouvé qui était très très visuel, qui marchait très bien, c'était les prises électriques. Si on a par exemple les prises électriques qui sont les mêmes d'un pays à un autre, c'est quand même pratique parce que l'électricité ça fait partie des choses qu'on doit faire transiter entre...
T'amènes ton seul cheveu en voyage, t'es content, t'as pas besoin d'acheter un adaptateur. C'est ça et c'est standardisé. En fait les standards ça nous rend la vie facile tout simplement.
Aujourd'hui tu veux ouvrir un fichier MP3 dans ton navigateur ou je sais pas avec VLC, ça marche parce que c'est un standard. PDF c'est un standard. Donc la standardisation, c'est vraiment quelque chose qui est nécessaire pour qu'on puisse tous avancer dans la même direction et puis créer de la valeur par-dessus tout ça.
Et ce qui est intéressant avec la notion de standard, pour reprendre la métaphore de la prise électrique, c'est qu'en fait, à un moment donné, c'est à quel niveau c'est décidé ? C'est-à-dire que tu pourrais te dire, au niveau des individus, chacun fait le truc dans son coin, un peu à sa tambouille, qu'à un moment donné, il y a un pays qui a dit Ouais, bon, quand même, là, on va mettre les mêmes deux trous pour tout le monde. Ce serait quand même pratique qu'au moins dans le pays, on soit tous à peu près raccordés pareil.
Un jour, les pays se parlent entre eux et disent Ah, toi, tu n'as pas les mêmes trous que moi ? Zut ! Bon, bien, on essaie qu'on ne fasse un peu les mêmes trous. Aujourd'hui, on connaît ça quand on voyage, parfois c'est compliqué.
Et du coup, c'est pour ça qu'on a encore besoin d'adaptateurs. Mais voilà, c'est juste pour dire qu'effectivement, la notion de standard aussi, elle arrive. Peut-être qu'on abordera ça un peu plus tard dans la conversation, mais en fait, standard avec un grand S versus peut-être standard avec un petit s, et en fait, à quel niveau ça définit ? Mais donc là, les standards dont on parle, en tout cas, qu'on essaye d'aller, C'est les standards avec un grand S, c'est-à-dire vraiment essayer de maximiser des choses dont on espère avoir une adoption maximale et du coup créer des comportements, en tout cas des formats qui vont être communs pour tout le monde.
Et donc il y a plusieurs groupes de travail qui travaillent dans le monde sur ces sujets-là, donc c'est des vrais gens, c'est pas juste l'Internet qui fait des choses magiquement avec des 1 et des 0 dans son coin. Tout ça en fait, c'est des gens. C'est des gens qui font des consensiums, qui se réunissent et qui parlent entre eux et qui essayent de décider de trucs qui ont un sens. Et donc le plus célèbre, il y a plein de communautés différentes, mais la plus grosse de loin et la plus connue, c'est une communauté qui s'appelle W3C, World Wide Web Consortium. Exactement. Alors pour ceux qui ne connaissent pas W3C, tu pourrais dire c'est quoi, ça a commencé quand ?
Alors le W3C, c'est donc une organisation qui a pour but de réunir toutes les personnes qui construisent le web. et ça a été créé par la même personne qui a créé le HTML, le CSS et HTTP. Cette personne, c'est Tim Berners-Lee.
Cette personne a créé ces différents langages dans les années 90 et vers la fin, il avait besoin de... d'un effort commun et d'avoir d'autres personnes qui puissent travailler avec lui, et même dans le monde, c'est-à-dire que pour que ce soit un standard qui soit adopté à l'échelle mondiale, il fallait différentes antennes, et il fallait que la parole puisse être prêchée, j'ai envie de dire, à grande échelle. Et donc l'organisation W3C réunissait des passionnés, et puis surtout des personnes, des industriels, tout simplement. Les premières personnes qui créaient des navigateurs devaient justement s'aligner sur certains standards, et donc il fallait une structure en fait.
Ce n'est pas du tout une structure à but lucratif, le W3C1. C'est vraiment... J'allais poser, est-ce que c'est des gens qui font ça en temps plein ou est-ce que c'est juste des gens, des volontaires, qui se disent, moi, je veux aider à construire le W3C1 ? Je pense qu'il y a les deux. Typiquement, il y a des personnes qui, à temps plein...
En fait, il y a forcément un juste milieu dans le sens où, pour apporter sa pierre à l'édifice et vraiment apporter de la valeur aux discussions dans la création d'un standard, il faut aussi comprendre ce qui se passe sur le marché. Donc, en fait, c'est souvent des professionnels qui... Qui l'appliquent à côté, surtout. C'est ça.
Et donc, qui remarquent, OK, bon, là, il y a, par exemple, un type d'usage différent. Je dis, bon, il y a quelques années, on se rendait compte, bon, là, aujourd'hui, les OS permettent d'activer ou de désactiver le fait qu'il y ait des animations à l'écran. Bon, si l'OS le dit, le navigateur peut peut-être récupérer cette information. Et donc, nous, développeurs de sites web, éventuellement, on pourrait se dire, si la personne n'a pas envie d'avoir des animations sur la page, moi, développeur de site web, et W3C, vous n'auriez pas un moyen, une information que moi, je pourrais utiliser en code pour savoir que si la personne n'a pas envie d'avoir des animations pour n'importe quelle raison, eh bien moi, je puisse l'utiliser et faire en sorte que cette animation SVG devienne un PNG statique, par exemple, ou des choses comme ça. Ils sont beaucoup plus intégrés.
Est-ce que tu pourrais le faire en code, toi-même ? Mais l'idée, du coup, avec le standard, c'est un peu avoir une espèce de boîte à outils dans laquelle tu peux piocher plus facilement, c'est ça ? Oui, parce que si, par exemple, je devais le faire en code, je devrais fournir dans l'interface directement du site un moyen de dire à l'utilisateur avant d'utiliser le site, tu sais quoi, paramètre-le un petit peu. Why not ? Et donc, tu as un impact.
Et donc, c'est là où ça rentre sur l'impact de l'expérience utilisateur. Exactement. Donc, il peut y avoir ça ou même la gestion des différents thèmes.
Quand on passe son OS en dark, en light, ce serait cool que les sites puissent s'en hériter. Donc, c'est pareil. Aujourd'hui, on a des standards qui, donc c'est le CSS avec ce qu'on appelle des media queries. on va se renseigner sur la manière dont le média de l'utilisateur, donc ici l'ordinateur, a été paramétré par l'utilisateur.
Et donc, tu veux que ton ordinateur fonctionne comme ça, eh bien, tu sais quoi, moi, je vais adapter mon site pour qu'il fonctionne de la manière dont toi, tu as envie. Très, très clair. Et donc, pour ceux aussi qui ne connaissaient pas avant cette discussion le W3C, il y a une forte chance quand même que vous soyez déjà tombé sur des standards mis en place par le W3C.
Tu en as évoqué quelques-uns tout à l'heure. Tu as dit, par exemple, PNG, SVG, JSON. Tout ça, si vous en avez entendu parler, vous l'utilisez dans vos vies de tous les jours, ça a été défini par des vrais gens qui se sont plongés sur la question un jour, qui continuent à créer d'autres formats potentiellement demain.
Et alors, parmi les trucs qu'on connaît bien en tant que designer, il y a aussi tout ce qui est la partie accessibilité. C'est-à-dire, si vous avez déjà utilisé un plugin Figma pour tester les contrastes, souvent ces plugins-là, ils se basent sur les normes, sur les standards WCAG. Alors, historiquement, deux.
Il y a le WCAG 3 qui est en cours de roll-out, si je ne me trompe pas. C'est pas ton sujet de prédilection, mais voilà. Et qui est en train d'unborder.
Alors ce qui est intéressant avec WCAG3, c'est qu'en fait, ils unbornent une logique de contraste qu'on appelle APCA, qui diffère du coup de ce qui était dans le standard précédent. Et en fait, c'est pas W3C eux-mêmes qui ont créé APCA, c'est une autre entité de chercheurs qui ont juste planché sur la question dans leur coin. et qui ont dit, maintenant, notre outil fait ça mieux que les autres. Et tu as W3C qui, de loin, fait, ah ouais, c'est vrai, et qui l'a abordé, et maintenant, c'est en train d'être roll-out comme étant un nouveau standard aussi.
Ce que tu dis, c'est intéressant parce qu'en fait, toute l'idéologie derrière le W3C, c'est un seul web pour tous, un seul web partout pour tous. Ça, c'est vraiment le leitmotiv du W3C. Et donc, ils estiment que l'ouverture du web, c'est le fait que si vous avez des bonnes idées...
on les prend et on améliore la vie de tout le monde. Et ça bouge très vite et très souvent, en fait. Très vite, pas forcément. Effectivement.
Ah oui, parce que ça a un impact. En tout cas, il y a toujours des améliorations. En tout cas, ils sont toujours en recherche, en tout cas, ouverts aux améliorations.
Et c'est grâce à cette mentalité que c'est aujourd'hui un des médiums les plus pérennes, en fait. Aujourd'hui, tu écris du HTML. Le HTML, c'est un langage qui est extrêmement stable. Et si on sait écrire du HTML, on est sûr que l'information qu'on va publier sur le web, elle va...
normalement vivre des années et des années, sauf si le serveur y prendrait. C'est vraiment, en tant que designer, surtout quand on ne sait pas coder, le HTML c'est en mode genre, wouh, c'est un univers à part, et ça a des règles bizarres, et on ne connaît pas trop, et en fait, c'est une langue quoi, et donc ça a les mêmes problématiques, c'est exactement les mêmes problématiques qu'une langue, qu'une vraie langue de la vie de tous les jours, où à un moment donné la langue elle bouge, et si la langue elle ne suit pas, si elle est trop rigide... Je vais y aller dire un message à la caménie française.
C'est ça. Mais voilà, il faut aussi adopter les... Si tu gardes une certaine flexibilité dans ta langue, tu la rends plus pérenne et elle évolue plus facilement aussi.
Mais dans le sens où c'est vraiment une langue, là, t'as raison, c'est qu'on va dire que c'est un langage qui est très haut niveau, parce que c'est un langage qui est fait vraiment à base de mots. L'ordinateur, à la base, il comprend des choses qui vont du zéro à du un. C'est très proche du hardware.
C'est très bas niveau. Et plus ce sera proche de nous, notre compréhension humaine, et qu'il y aura de plus en plus de mots, on va dire que c'est haut niveau. Le HTML, quand on veut un titre de niveau 1 et un titre de niveau 2, on appelle ça un heading, et un titre de niveau 1, ça va être une balise H1.
Une liste, ça va être, si elle n'est pas ordonnée, ce sera un ul, parce que c'est un ordered list. Et un élément d'une liste, ce sera li, parce que list item. Donc en fait, c'est un petit langage qui... qui finalement, une fois que ces mots-là, on les a en tête, c'est pratique. Mais à un moment donné, il y a des gens qui se sont dit, puis à un moment, il y a des gens surtout qui se sont dit, genre ça, on l'appelle comme ça, mais en fait potentiellement demain, il y a des gens qui pourront dire, en fait, on change cette règle-là et ça va s'appeler autrement.
Ça peut avoir un impact, effectivement. Mais oui, c'est des langages qui évoluent parce que les usages évoluent et parce que le web aujourd'hui, c'est comme l'eau. Il est partout dans nos vies. Des gens qui râleraient un peu plus, à mon avis, s'ils n'ont pas préféré avoir Internet que la clim en été, par exemple. on en est à aujourd'hui votez dans le chat climat netteté ou internet non mais normalement aujourd'hui il n'y a plus internet limite tu l'entends plus que la lumière elle a pété dans la pièce par exemple enfin c'est internet de toute façon c'est biaisé et du coup au sein de tout ça donc il y a W3C j'ai vu quelqu'un un message passé qui disait W3C c'est l'académie française des internets l'académie mondiale on va dire ça C'est la communauté de l'anneau du web, on va dire ça comme ça.
Donc tu as W3C et en fait, du coup, toi, tu fais partie de Design Tokens Community Group. C'est quoi le lien entre les deux ? D'où ça vient ?
Explique un peu. Le W3C regroupe toutes les personnes qui veulent contribuer au web. Dans ces personnes-là, il y a des industriels, il y a des particuliers qui sont passionnés et donc il y a différents types de groupes au sein même du W3C.
Les personnes, par exemple, qui... font évoluer les langages HTML, CSS, SVG, PNG, ces choses-là, ces différents standards. C'est des choses, c'est vraiment ancré dans le marbre, c'est du très sérieux et on ne peut pas trop s'amuser avec ça.
Donc en fait, ça va être des groupes qu'on va appeler des working group. Et c'est des personnes souvent qui vont travailler même dans les différents navigateurs. On va principalement retrouver des industriels. Par exemple, on va retrouver des gens de chez Google, de chez Microsoft.
Ça dépend, mais en tout cas, les personnes des Working Groups, ce sont vraiment des personnes qui vont penser à grande échelle des impacts sur l'évolution de certains standards. Demain, les balises HTML H1, on les appelle Heading 1. problème, problème, problème, problème, parce qu'énorme impact. Il y a des working group. Ensuite, on a des groupes différents qui vont pouvoir regrouper des passionnés.
Et les community, c'est par exemple ce qu'on appelle aussi des community group. Les community group, c'est typiquement des groupes de gens passionnés, comme nous, on en fait partie. Donc, nous, le DTCG, c'est Design Tokens Community Group.
Et donc, c'est des passionnés du... du web et donc plus particulièrement le sujet des design tokens qu'on a réunis, je dis ont, mais qui ont été réunis dans le but justement de définir un standard et si ce standard demain devient suffisamment solide, implémenté à grande échelle, le W3C pourrait décider de, ok, on choisit de prendre cette bonne idée-là et d'en faire une norme plus ou moins solide. Et si cette norme, elle est...
elle passe à ce stade-là, les navigateurs pourraient décider d'en faire quelque chose et donc on se retrouverait demain avec quelque chose qui est vraiment lié au design token dans les navigateurs, par exemple. Mais là, aujourd'hui, on a différents groupes de travail parce que vous avez envie de participer au web, eh bien, voici un groupe de travail pour vous. Et concrètement, ça ressemble à quoi ?
Pas forcément le quotidien, parce que je ne sais pas si c'est un travail vraiment quotidien en tant que tel, mais en tout cas, les actions, les interactions avec les autres membres du DTCG, est-ce qu'il y a des rituels, est-ce qu'il y a des milestones, est-ce qu'il y a des frameworks que vous utilisez ? Ça ressemble à quoi ? Alors, par exemple, nous, on est réunis toutes les deux semaines.
Et quand je dis nous, c'est on est un groupe. Donc, le DTCG, c'est un groupe de travail qui travaille sur le format standard des design tokens. et on a des types de design token, par exemple, qui sont assez précis.
Par exemple, couleur. Une couleur. Et les couleurs, c'est à l'intérieur du DTCG, il y a des gens qui ne travaillent exclusivement que sur la couleur parce que la gestion des espaces colorimétriques, les écrans...
À nouveau dans la partie des sujets qu'en tant que designer, parfois, on ne connaît pas assez. L'espace colorimétrique, quand on commence à regarder plus près, c'est genre... Ah oui, c'est vraiment ça.
Donc, il y a des gens qui sont spécialisés là-dessus. Néanmoins, il y a un socle commun au sein du DTCG qui est un token. Ça doit avoir un nom, ça doit avoir une valeur.
Et ça a différentes propriétés. Et si vous travaillez sur les couleurs, en tout cas, nous, les décisions qu'on va prendre, ça va vous impacter aussi. Donc, par exemple, que vous travaillez sur les couleurs ou les animations, les personnes au sein du DTCG vont pouvoir bénéficier du travail sur le standard, le format en lui-même. Donc moi, je fais partie du groupe, du format en lui-même, avec d'autres personnes, notamment James Nash, avec qui j'avais pu présenter le standard en 2022 à Schema. Et typiquement, comment ça marche ?
Eh bien, on se dit, on est là, on est sur Slack, on a au sein du Slack Design Systems, on a un channel privé et on se dit, bon, venez, on se voit toutes les semaines. Ah, OK, ça ne marche pas trop pour vous en termes d'emploi du temps, parce qu'en fait, on a tous un job à côté. Oui, oui, il y a rien à voir. Donc on se dit...
Ah, et puis toi, tu es sur tel fuseau horaire ? Oui, en plus, c'est international. C'est ça, et il faut s'organiser. Et puis, il y a la vie. Mon fils, il est malade, je ne peux pas venir.
Mais là, aujourd'hui, on devait parler de tel sujet. Et les personnes qui sont réunies aujourd'hui n'ont pas forcément les compétences pour traiter ces sujets précis. Là, on avait besoin des compétences techniques de cette autre personne qui n'est pas forcément disponible.
Bon, on va peut-être décaler ça à deux semaines, etc. Donc, en fait, c'est vraiment de l'organisation, tout simplement. Alors, il y a effectivement des milestones pour que...
le temps qu'on passe ensemble c'est une heure toutes les deux semaines en tout cas c'est nous comme ça qu'on a décidé de travailler c'est important quand même de se fixer des objectifs parce que tu peux très vite te dire bon bah en fait on a passé une heure ça va vite mais il n'y a pas grand chose qu'on a élucidé et puis on parle d'un sujet qui est quand même assez complexe on parle de token et donc de choses qui peuvent aussi ne pas être très tangibles quand on est juste là à parler de choses complexes à l'oral et donc... C'est important de faire en sorte que le temps qu'on passe ensemble, il puisse avoir de la valeur. Et donc, voilà, tout simplement, c'est de l'organisation. Et là, on a deux objectifs en ce moment. Le premier est lié aux espaces colorimétriques.
Il y a des nouveaux espaces qui sont apparus. Pour ceux qui ne connaissent pas du tout les trucs espaces colorimétriques, la version Explain to me, explique-moi comme si j'avais 50. Quand on crée une couleur, on a du rouge, du vert et du bleu et ça fait une couleur sur, allez éventuellement 256 possibles avec ça sauf que 256 couleurs possibles c'est peut-être pas assez il en faut beaucoup plus parce que le spectre est bien plus large que ça et donc il faut que graphiquement, en fonction des écrans de chacun, en fonction des technologies qui permettent de calculer une couleur et de donner à un écran une valeur de pixel précise Il faut qu'il y ait différents algorithmes qui puissent être plus ou moins larges. Et donc, il y a des espaces colorimétriques qui permettent de donner de la flexibilité aux gens pour avoir des bonnes couleurs. Un photographe va travailler avec des espaces colorimétriques qui sont bien plus larges, parce que quand on est sur de la photo, on n'a pas les mêmes besoins que quand on crée une interface et qu'on a envie d'avoir un bouton rouge ou un bouton vert.
J'allais dire, moi j'ai eu une expérience en print avant de basculer côté digital. Print, c'est du PNJ, c'est pas pareil. Exactement, et c'est vrai que c'est... À nous, on revient sur la question des modèles mentaux, mais c'est vrai que c'est tellement différent. Moi, j'allais sur les runs, j'allais en impression industrielle dans les usines, à faire le contrôle, et en fait, tu es sur une notion de rajouter un tout petit peu plus de jaune, rajouter un petit peu plus de bleu, de cyan, et c'est très physique, et tu as l'épreuve physique, on va dire, et on va dire au final, ce que tu sors en termes d'impression quand c'est ton run de production, c'est ce qui va être fait.
Alors, oui, t'as... Il y a des petites variations, c'est-à-dire que tu tolères une certaine variation, tu définis un minimum, un maximum, en disant plus ou moins saturé, et derrière, il y a un contrat avec le supplier pour qu'il produise dans ce minimum et ce maximum. Mais grosso modo, tu vois le rendu final et tu le contrôles en temps réel. par des ajouts parfois à la goutte près de teintes, de couleurs physiques, de peintures. C'est de la chimie.
C'est comme des cours de peinture. Et c'est vrai que quand tu débarques dans le digital, où là d'un coup tu parles de lumière avec des pixels et tu as plein de technologies physiques, de hardware derrière ça, des écrans qui se comportent différemment en fonction des générations, en fonction des marques qui les produisent. C'est encore un autre monde. Donc je pense que tout le monde n'a pas forcément en tête ces différents...
Non, mais effectivement, c'est intéressant ça. Parce que finalement, ça c'est pareil, c'est des standards qu'on utilise dans la vie de tous les jours. On a un écran, il y a des couleurs qui s'affichent, on se dit, bah oui, normal.
Il y a des belles couleurs, parce qu'il y a des gens, ils ont mis beaucoup de matière grise dans la balance. Donc il y a l'espace colorimétrique, on a envie de permettre aux tokens de gérer des espaces colorimétriques qui sont plus larges, parce que jusqu'à maintenant, par exemple un token de type couleur, une valeur ne pouvait contenir que... d'une valeur qui était de l'hexadécimal ou du RGB. Elle est potée la question.
Par exemple, les standards, entre guillemets, enfin, j'imagine que c'est des standards, ex, RGB, HSL, etc., c'est aussi W3C ? Je ne sais pas. Je ne sais pas assez là-dessus. On considère ça comme des standards, non ? Peut-être.
Je pense que c'est des valeurs, en fait, étant donné que, par exemple, l'hexadécimal et du RGB, tu peux basculer de l'un à l'autre sans perdre de la donnée. C'est le même espace colorimétrique, et ça se trouve, la gestion des espaces colorimétriques fait peut-être partie du W3C, ou pas, mais en tout cas, là, c'est juste une manière d'afficher le 2. Et il y a un autre sujet, et qui suit là aussi très important, sur lequel on est en train de se pencher, c'est en fait la gestion des contextes de couleurs. J'utilise le mot contexte vraiment en faisant exprès, je n'ai pas dit thème, parce que thème, j'estime que c'est un petit peu réducteur. on peut très bien avoir une page avec une section en blanche et une section en noir et avoir les mêmes éléments qui changent de couleur et pour autant la page elle a pas un thème light ou un thème dark il y a une section qui a un contexte noir et un contexte light par exemple mais il faut justement permettre au design token de prendre en compte ces différentes valeurs en fonction du contexte dans lequel ils sont et donc la gestion du theming aujourd'hui c'est quelque chose qui c'est complexe et on est en train d'y travailler hum Et donc, mettons, demain, en gros, il y a convergence, on va dire, au sein du community group.
C'est par exemple une question d'espace colorimétrique. Ça ressemble à quoi, en fait, le cycle de vie dans Standard, on va dire, à partir du moment où vous êtes plus ou moins d'accord ? Qu'est-ce qui se passe quand les discussions commencent à aboutir sur quelque chose ? Quelque chose, il se matérialise comment ?
Et derrière, où est-ce qu'il va ? Une fois qu'on se met d'accord, alors déjà, se mettre d'accord, ça veut dire prendre des notes. pendant les réunions. Et c'est super important parce que si on parle de choses complexes et qu'on ferme l'écran et on fait Bon, ben, salut, à dans deux semaines. Ah, on a parlé de quoi la semaine dernière ?
Compliqué, voilà. Donc déjà, il faut prendre des notes. Une fois qu'on s'est tous mis d'accord, on crée ce qu'on appelle une spécification. Donc, c'est un document qui a une structure qui est elle-même définie par le W3C, qui dit, le W3C dit au groupe, si vous voulez prendre des décisions, voilà comment vous devez les matérialiser et les définir.
Et si, par exemple, de la version 1 à la version 2, il y a eu des changements, voilà comment vous devez modifier les documents de telle sorte à ce qu'on puisse comprendre section 1.1. Eh bien, il y a eu des changements qui ont été faits. C'est comme du versionning un peu. D'ailleurs, c'est de la documentation. C'est vraiment de la documentation parce que l'historique de décision, c'est super important de le garder en place aussi.
Parce que sinon, on peut se retrouver dans un cas où… Ah, mais si on essayait ça ? Ah oui, mais il me semble qu'on a déjà fait ça la dernière fois et ça n'avait pas marché. Ah bah oui, mais on ne l'a pas documenté. Bon, bah super, on va répéter nos erreurs. Et du coup, une fois que tu as la docu derrière ?
Une fois que tu as la documentation, tu normalises tout ça, tu en fais éventuellement un blog post sur le site du W3C ou en tout cas sur le site de ton community group. Nous, c'est par exemple ce qu'on avait fait pour le premier draft des design tokens qu'on avait sorti il y a un an et demi, deux ans, il me semble. Et à partir de ça, les utilisateurs de ton standard.
Donc, dans notre cas précis, les utilisateurs du standard, ce n'est pas les utilisateurs finaux des sites web ou des outils design, c'est les créateurs d'outils. Et ça, c'est important de le préciser parce qu'il y a des cas, donc typiquement, les standards d'accessibilité type les standards, enfin, typiquement, je pense à des plugins de contraste, mais aussi, par exemple, des normes ARIA qui sont des normes qui vont dans le code front-end pour les devs qui permettent d'intégrer tout ce qui va être accessibilité. Ça, les utilisateurs finaux, c'est donc les front-end et les designers. Et notamment les outils. Et aussi les outils, oui.
Mais il y a une partie qui impacte directement. Parce que la norme est littéralement à la fin dans le HTML. Dans le processus, exactement. Alors que vous, du coup, côté design token, ce n'est pas forcément exactement pareil. Nous, ce qu'on permet de faire, le standard permettra aux utilisateurs finaux de créer un token dans un outil.
Par exemple, je crée un token dans Figma. tous mes tokens de couleurs, par exemple, je peux les réutiliser, imaginons, dans Word. J'ai envie d'avoir exactement les mêmes couleurs.
Bon, eh bien, j'ai envie que la donnée que je crée dans Figma, elle puisse être utilisée dans Word. Donc, techniquement, j'ai cette donnée qui doit transiter des serveurs de Figma au serveur de Microsoft. Cette donnée-là, elle doit avoir un format qui est comprise par les deux.
Typiquement, nous, on utilise du JSON. Donc, on se base sur le standard JSON pour créer le... Et en fait, nous, le standard des tokens, c'est globalement...
Un token, ça doit avoir une propriété name et une string. Une propriété value, et ce ne sera pas une string la value, ce sera peut-être quelque chose de plus complexe parce qu'on a envie de mettre beaucoup plus d'informations à l'intérieur d'une valeur. Et puis peut-être une propriété commentaire, j'ai des choses comme ça.
Mais ça, c'est tout simplement, qu'est-ce qu'on a envie qu'un design token véhicule comme information qui puisse avoir de la valeur entre un outil et un autre. Ces outils-là, une fois qu'ils supportent le standard, permettre aux utilisateurs finaux, les designers, les développeurs, d'avoir de nouvelles fonctionnalités, de pouvoir faire des choses. Mais in fine, ce ne sont pas les utilisateurs finaux, ce sont vraiment les créateurs d'outils. Et c'est marrant parce que je reviens, j'ai rejoint Figma en novembre 2022. Pour la petite histoire, pendant mes entretiens d'embauche, ils m'avaient demandé c'est quoi les trois fonctionnalités que tu voudrais d'un Figma ?
Et deux de ces fonctionnalités sont sorties de lui. Et d'ailleurs, une, c'était en gros gestion native des tokens. Et donc...
forcément les travails sur les variables étaient déjà commencés à ce moment-là, puisqu'elles sont sorties à peu près 6, 7, 8 mois plus tard. Et je me souviens que la question c'était surtout pourquoi c'est pas sorti avant. Et une des raisons, enfin quand je commençais à dépierter le sujet avec les équipes qui travaillaient dessus, ils me disaient parce qu'en fait on essayait vachement de s'aligner avec les standards de TTCG que vous étiez en train de travailler et que du coup on attend qu'il y ait un bon niveau aussi de maturité sur ces standards-là pour pouvoir justement gérer tout ça. C'est ce qui est normal. Et donc, en fait, pour give un shout-out, en gros, si vous avez les variables d'amphibie aujourd'hui, on porte parti grâce au travail de Louis et d'ATTCG.
Mais c'est important ce que tu dis, parce que l'impact, en fait, tu ne sautes pas direct à l'eau sans que tu sois sûr, parce que ça aura un impact qui est très important, sachant que quand on crée des standards et quand on crée des choses comme ça, il faut qu'il y ait une pérennité qui soit vraiment inhérente au travail. Donc, par exemple, les media queries, c'est par exemple... Donc, les médias queries en CSS, c'est un moyen de dire si le navigateur de l'utilisateur est dans tel contexte, alors la page va réagir comme ça.
Le navigateur... Du coup, c'est pour du responsive ? Notamment.
Ok. Si le navigateur a une largeur de 800 pixels, j'ai peut-être envie d'avoir des éléments qui vont se mettre les uns en dessous des autres. Comme ça, le site est lié. Ok, clair.
Par exemple, les médias queries, le groupe... Les working group, les personnes qui travaillent à ça, elles ont commencé en 2001. C'est sorti en 2012. 11 ans pour... Ça prend du temps.
On fait review, on fait revoir le travail, les documents par différentes personnes à droite, à gauche. Et ça peut prendre du temps. Et après, on rajoute des choses en plus.
Quand c'est sorti en 2012, la media query qui permettait de déterminer si le navigateur était dans un contexte où... il faut que j'affiche des animations ou pas. L'utilisateur, il l'a dit à l'OS. En fait, ça, ça n'existait pas à la sortie.
Donc, en fait, il y a aussi des nouvelles versions de ces standards qui sont mises à jour. Et bien, ça, ça prend du temps, en fait, parce que ça a un impact qui est très fort dans la vie des gens de tous les jours. Donc, voilà, ce n'est pas un travail à prendre à la légère. J'ai une très bonne question qui est arrivée dans le chat et j'avais très envie de la poser. Ok, go.
Donc, on dit effectivement que vos utilisateurs principaux, les personnes avec qui vous parlez en priorité, qui vont vous aller impacter, c'est les outils. Et du coup, en tant que designer advocate, j'ai souvent des questions de, mais du coup, mes tokens, je dois les faire comment ? Et donc, quelqu'un, c'est Ludovic, qui pose la question dans le chat. Du coup, est-ce que le W3C, donc en l'occurrence plutôt le DTCG, impose une norme de nomenclature des tokens ?
Car je trouve énormément de nomenclatures différentes et des fois très complexes. OK. Allez ! Merci les deux d'avoir posé la question.
Quand on parle de nomenclature de token, on va principalement parler de comment est-ce qu'on peut nommer des tokens. Moi, tout à l'heure, quand j'ai dit qu'un token devait avoir une propriété name et... C'est une string, donc une chaîne de caractère.
Cette chaîne de caractère, nous, dans le standard, c'est une chaîne de caractère. C'est tout ce qui est défini. Et si on va plus loin que ça, nous, potentiellement, étant donné qu'on n'a pas la science infuse, ni le spectre, et qu'on a envie que le standard, il ait du sens même encore pendant 10, 15, 20 ans.
En fait, prendre une décision sur, voilà comment vous devez nommer les tokens et l'inscrire littéralement dans la spectre, ce n'est pas bien. Maintenant, Parce que ça impacterait la pérennité du standard. Néanmoins, ce qu'on peut faire, c'est partager des bonnes pratiques sur... Aujourd'hui, on remarque qu'il y a des équipes qui nomment leurs tokens comme ça.
Elles l'ont documenté. Typiquement, je pensais à Sana, qui était venue à Confi il y a quelques années, et Gina Han, donc une des co-créatrices du DTCG, avec Kaelik de l'Homo Prigent. Ils avaient justement expliqué leur manière de nommer les tokens. Et comment... Et pourquoi ?
Et pourquoi ? Et en fait, quand je dis qu'elles ont expliqué leur manière de nommer les tokens... elles ont expliqué au monde leur langage design qui faisait sens pour leurs équipes. Et je veux vraiment qu'on accentue sur le côté langage design parce que nommer des tokens, c'est ni plus ni moins qu'au lieu de dire est-ce que la couleur rouge, elle te va ?
Elle est rouge, déjà, c'est cool, ça parle à tout le monde. Si demain, on venait à se parler en RGBA dans la vie de tous les jours, ça n'irait pas trop. Est-ce que tu veux mettre la couleur ? 0-0-F-F-0-0. Les robots, ils s'occupent de ça pour nous.
Mais nous, on a besoin de mots pour communiquer des tokens. Cette animation qu'on va appeler fast, non, celle-là, il ne faut pas l'utiliser parce que pour tel pattern design, ce n'est pas ça qu'il faut utiliser. Il faut utiliser l'animation slow.
Là, je viens de donner un exemple bête, mais il faut mettre des mots sur des choses qui sont rajoutées du tangible, sur des choses qui ne sont pas forcément tangibles. Et un token, à la base, ce n'est pas forcément quelque chose qui est tangible. Ok, c'est des couleurs, c'est des styles de texte, c'est des animations.
Ok, on voit à peu près ce que c'est. En fait, c'est surtout un usage. C'est un usage. Et donc, établir un langage commun, établir une nomenclature, c'est quelque chose qui doit se faire entre toutes les parties prenantes qui vont créer et consommer des tokens. Cette nomenclature, pour une équipe, pour une organisation, ou un groupe de personnes données, ça peut être à différentes échelles.
Et je parle de designer et de développeur. Tout à fait. Ah oui, c'est tout l'intérêt du truc.
Voilà, les développeurs vont principalement les consommer, ce n'est pas forcément eux qui vont dire, bon en vrai, le développeur va consommer des tokens, il va donc dire, ah bah tiens c'est marrant, quand j'inspecte dans Figma tel élément d'interface, je vois qu'à chaque fois c'est primary color, ça ne me parle pas trop, ça me dit, on change le mot, parce que nous, on a du mal aussi à anticiper le système que vous, designer, vous avez mis en place, et le principe c'est quand même que ça aille plus vite. Et puis aussi de gérer accessoirement potentiellement des modifications, c'est-à-dire il faut aussi assurer une certaine pérennité, une certaine flexibilité dans ton système pour qu'il puisse potentiellement scaler. C'est ça. C'est-à-dire que c'est bien de dire rouge, vert, bleu, sauf qu'à un moment donné quand tu auras 10 nuances de rouge différentes, peut-être que tu vas te rendre compte qu'en fait Red tout seul, il faut commencer à spécifier un peu c'est quoi ces différents rouges puis même encore aller au-delà de la chose tu veux dire à un moment donné, mais en fait là le rouge il est utilisé dans plein d'endroits différents, comment est-ce que j'anticipe à quel endroit je vais utiliser quoi ?
C'est là où tu arrives sur une logique sémantique de plus axer sur l'usage que la matérialité en tant que telle du token. Exactement, c'est pour ça qu'aujourd'hui on a deux types de tokens principaux. Quand je dis deux types de tokens, on a deux types de manières de nommer les tokens.
On a une manière qui est absolument bête et méchante, RAID 100. C'est une première nuance de rouge dans une échelle qui pourrait éventuellement aller de 100 à 900. Et on a 9 options. Parmi ces 9 options, il y en a une qu'on va choisir et qu'on va dire, je veux que la première nuance de rouge, on l'utilise, imaginons s'il y a une notification pour dire, attention, il y a un truc un peu dangereux qui vient de se passer, ou c'est, fais attention, eh bien, ça va être la couleur de fond de la notification. Et donc, c'est peut-être lié à une interaction qui est liée, qui communique un danger.
Et donc... Le red 100, on va donc l'associer à quelque chose qui a un peu plus de sens dans le contexte de l'interaction qu'on a avec l'utilisateur, qui est background color danger, par exemple. Et ces deux tokens-là doivent exister.
Mais il y en a juste un qui, dans un contexte précis, parle plus. Parce que demain, si on décide de dire cette couleur de fond, elle ne va pas, c'est plutôt red 200 qu'il faut utiliser. Très bien, c'est pas grave.
Et je pense que quand tu dis parle plus, c'est ça justement qui est important. C'est encore une fois, pourquoi ? tu l'appelles comme ça et le pourquoi tu l'appelles comme ça c'est avant et tout c'est de la communication c'est aligner des gens pour que tout le monde au sein des équipes parle la même langue comprenne les mêmes choses et on revient on parlait tout à l'heure de comparaison entre les langues internet les langues CSS HTML et compagnie et on disait en fait c'est des langues donc ça vit comme des langues comme de français comme l'anglais et tout ça et en fait les tokens c'est pas si éloigné et donc le pourquoi ça existe C'est créer de la communication et l'intérêt, et donc pour ça, pour revenir, parce que j'adore cette question Ludovic, parce qu'on me pose tellement souvent la question de et comment je dois nommer mes tokens ?
Et à chaque fois je dis... Ça dépend, est-ce que vous en avez parlé avec vos équipes ? Alors, je n'aime pas dire ça dépend, mais c'est vrai.
La réponse courte, c'est qu'il n'y a pas de normes, ce n'est pas normé. Ce n'est pas normé. Et c'est volontaire que ça ne soit pas normé.
Il n'y a pas de règles ABCD à suivre. Ça, vous trouvez la solution. Et c'est vraiment spécifique au contexte à chaque fois des équipes.
Et en vrai, de façon très réaliste, si vous voulez appeler votre token Bob, vous avez le droit d'appeler Bob. Et si tout le monde sait ce que Bob est... et bien Bob ça marche ça c'est un très bon exemple par exemple il y a un article de Dan Moll au niveau des styles de texte quand on parle de couleurs tout à l'heure il y a pléthore de couleurs qu'on peut utiliser dans un système et dont on a besoin d'ailleurs mais cette quantité de tokens on aura besoin de beaucoup de couleurs par contre en termes de style de texte une dizaine de styles de texte différents en vrai ça devrait pouvoir nous permettre d'avoir une interface et une information qui est correctement hiérarchisée donc si on a envie d'avoir les tokens de style de texte qui ont... Il y en a cinq, et on va dire Marge, Homer, Lisa, Barthes et Maggie. Et bien, on y va.
Et après, la limite, c'est que rapidement, les gens ne comprennent pas. Là, là-dessus, en termes de sémantique, c'est compliqué. Parce qu'on pourrait peut-être se dire, Homer, c'est quoi ? C'est peut-être le plus gros des cinq. Donc, on va dire que c'est le H1.
Bon, peut-être, mais ce n'est pas forcément clair. Si ça se trouve, c'était autre chose. Donc, il y a cet aspect sémantique qu'il faut absolument... faire transpirer via le nom d'un token, qui est important, parce que sans la sémantique, on ne peut pas, en tant que consommateur d'un token, on ne va pas comprendre dans quel contexte il va servir. Et en fait, si on ne comprend pas dans quel cas on doit utiliser un mot ou un autre dans la vie de tous les jours, on ne va pas l'utiliser ce mot.
Et bien c'est pareil avec un token. Je vois des questions, j'aimerais essayer de répondre à quelques questions du chat. On n'aura pas le temps malheureusement de tous les couvrir. Je vous invite à recontacter Louis directement. C'est quoi tes plateformes préférées ?
Plus Twitter malheureusement, par Envreslac. Sur quelle communauté ? Sur Community Design System France.
Et Community Design System Monde aussi. Je suis sur les deux et là-dessus je suis très accueilli. Je rajouterai les liens du coup sur le Figjam Board et ceux qui sont encore en viewer dessus pourront y accéder et cliquer dessus. Très bien.
Donc voilà, n'hésitez pas à lui poser des questions. S'il y a des questions Figma, je suis joignable sur LinkedIn, vous pouvez m'envoyer des messages. Ou alors sinon, contactez-moi sur...
Alors, je suis encore sur Twitter, techniquement. Je suis encore sur Twitter aussi, mais les DM, c'est un peu plus galère. Donc voilà. Et donc juste pour répondre, est-ce que tu as des exemples du coup de...
La question telle qu'elle est posée, c'est de gros projets tokens qui ont bien fonctionné, mais plutôt d'équipes où tu te dis, OK, là, il y a un niveau de maturité intéressant. Et en plus, ils ont open source. En tout cas, ils ont mis en ligne, soit sur Figma, soit sur leur propre plateforme, un peu une... Je pense à Material, par exemple.
Je ne sais pas s'ils font grand-chose avec la token, mais en gros, des trucs où les gens peuvent consulter. Zirwa, c'est une base intéressante. À nouveau, faites attention avec les bonnes pratiques. Toujours, posez-vous de challenger.
Posez-vous la question d'est-ce que c'est pertinent pour mon équipe ? Alors, il y a beaucoup de design systems qui sont open sourcés et qui sont mis publiquement. Je pense, en fait, les plus connus, ça va être Polaris de Shopify. On aura Carbon de IBM.
Ils portent les tokens dedans ? Justement, il y a les tokens. D'ailleurs, ce qui est intéressant, notamment avec Polaris et Carbon, c'est qu'en termes de type de token, ils vont assez loin. Même les tokens d'animation, des choses comme ça. Encore une fois, vous n'avez pas besoin d'aller jusque-là.
Pas parce que les meilleurs gens le font que vous avez besoin de le faire. Concentrez-vous sur ce qui apporte le plus de valeur au départ. On pose ce qui se voit sur une interface, les couleurs, les espacements, les styles de texte. Exactement. Les trois premiers points.
Commencez petit et ne visez pas... la méga usine à gaz de Toshiba et plus récemment Scaleway ils ont leur design system qui est en open source aussi donc en fait c'est bien de faire de la veille de regarder comment est-ce que les autres boîtes elles font et de s'inspirer de ça très bien on arrive vers la fin on a déjà un tout petit peu dépassé je voulais finir sur une question pour partager des ressources donc si jamais il y a des gens j'ai vu qu'il y avait des gens dans le chat qui réagissaient et qui ont l'air d'être déjà vachement au fait de ces questions-là donc on va poser peut-être la question deux fois déjà pour les gens qui sont déjà à fond, qui sont très intéressés, qui ont envie un peu de participer à ces discussions. Est-ce qu'il y a une porte d'entrée pour rentrer dans ces discussions de community group ? Est-ce que vous acceptez des membres ? En gros, les gens qui veulent s'impliquer davantage, par où ils passent ?
Par où ils passent ? Le Slack Design Systems. Vraiment, c'est la plus grosse communauté design system au monde avec beaucoup de channels qui sont créés sur différents types de sujets. Il y a typiquement un channel Design Token où, quand on pose une question, il y a les experts du marché qui viennent y répondre. Donc là-dessus, c'est vraiment une mine d'or dans laquelle il ne faut pas s'en passer.
Et vous pouvez envoyer des DM aux gens et on accepte du monde au sein du DTCG. Typiquement, une des dernières personnes qu'on a accueillies, qui est Mike Kaminga, qui est un des co-créateurs de Token Studio. parce qu'ils sont spécialisés, bien sûr.
On a besoin de personnes pour nous aider un petit peu. Et donc, on l'a accueilli. OK, très bien. Donc voilà, ceux qui sont à fond et qui sont très bons là-dessus, vous pouvez faire ça.
Alors, pour les gens qui, par contre, eux, débarquent, sont venus plus là pour apprendre vraiment les bases, mais qui sont plus créatifs, mais qui n'ont pas forcément les appétences techniques, mais qui ont envie d'apprendre davantage, est-ce que tu as des bons endroits par où commencer à prendre un peu ces sujets-là en main de façon très pédagogique ? J'aurai des articles, j'aurai des vidéos. On les a mis sur le board pour certains. En tout cas, pour démarrer de manière très générale, il y a un autre article qu'on va rajouter, qu'on pourra rajouter dans le board pour l'instant.
Les différents articles ont été partagés sur des types de tokens précis. Mais pour avoir une vue un petit peu plus d'ensemble, on va rajouter un autre lien après. Super. Du coup, on vous envoie un petit sondage juste pour prendre vos retours sur ce format.
À nouveau, on est au tout début, c'est tout bébé. On a encore pas mal de... Enfin, on va essayer d'en faire un chaque mois.
Donc, on est très preneurs des retours, notamment pour savoir si ce format vous plaît, savoir si le sujet est intéressant, si il y a d'autres sujets qui vous intéresseraient. Donc, voilà. Merci de nous faire partager tout ça pour qu'on continue à améliorer. Et du coup, teasing, pour la prochaine fois, le prochain Coffee Break, on le fera à peu près à la même heure.
J'espère qu'elle vous convient. Ça sera le 13 novembre et on parlera IA. qui n'est pas un petit sujet. J'ai très, très hâte de cette conversation. On va accueillir Mathieu Badimon, qui est Head of Design chez Photorome.
Photorome, c'est un autre produit, un peu comme Figma. Alors, pas comme Figma exactement, parce qu'on n'est pas sur les mêmes domaines. Mais en gros, c'est des outils d'édition créative qui embarquent de l'IA. Et on va se poser plein de questions sur c'est quoi de designer de l'IA dans des outils créatifs ?
C'est quoi les questions qu'on se pose côté design quand on crée ces fonctionnalités-là pour d'autres créatifs ? Et puis en fait, c'est quoi l'impact derrière sur la notion de design craft, sur nos métiers, etc. Je sais que c'est un sujet qui est très d'actualité, que beaucoup de personnes ont envie d'explorer. Donc je suis très, très heureuse qu'on puisse accueillir Mathieu le mois prochain.
Surtout qu'il a travaillé sur le design système d'Adobe. Oui, c'est un peu une pointure parce que Mathieu Badimon est rentré récemment en France depuis SF et il était chez Adobe avant. Et il était notamment un des leads du design système d'Adobe.
Donc rien que ça. Voilà, voilà. Merci à tous de nous avoir rejoints. On espère que le café est fini et bon après-midi. Bon retour au travail.
Ciao, ciao.