Aller directement au contenu

Switch language:

L'éco-conception c’est obligatoire si on veut optimiser l'expérience utilisateur, interview de Ivan Dalmet, Lead Designer UI/UX au Bear Studio

Rédigé le 28/02/2023 par Youen Chéné Eva Giffard

INTERVIEW

L’optimisation des sites et des applications web pour l’utilisateur

Cette semaine, c’est un ancien collègue que j’interviewe, Ivan Dalmet. C’est un UX Designer de métier et on va parler de son expérience d’optimisation des sites et applications. On ne va pas en parler pour l’impact écologique, mais pour fluidifier au maximum l’expérience pour les utilisateurs.

Ivan Dalmet avec sa mimick double pouce haut devant le kakémono Bear Studio

Interview

Peux-tu te présenter ? Ton parcours, ta vie, ton œuvre ?

Je m’appelle Ivan, j’ai 33 ans. Ça fait maintenant 12 ans que je travaille dans le web. J’ai commencé par créer une agence à 5 auto-entrepreneurs, la pire idée du siècle parce qu’on était trop. J’ai commencé dans le web en tant que web designer sachant que je faisais un peu plus de design, mais je savais coder.

Ensuite tu es allé dans une petite agence web dans une imprimerie ?

Oui, on était trois : deux développeurs et une commerciale dans une PME d’une soixantaine d’employés. C’était du site classique en Wordpress. Avec la problématique qu’il n’y avait pas grand-chose de responsive dans les thèmes (Note : pas adapté à toutes les tailles d’écran). On se rendait compte rapidement que l’on devait repartir de zéro sur le thème pour profiter de toutes les possibilités de WordPress d’administration de contenu.

Particulièrement, les ACF (Note: Ajout de champs configurables) qui permettait de transformer WordPress en vrai CMS sans avoir un Builder.

Le problème des builders, c’est qu’ils générent du code automatiquement. De plus, les administrateurs de contenu n’avaient pas de connaissances très poussées. Généralement, en production, sur mobile, la mise en page était cassée.

Maintenant si tu prends les gens qui utilisent Wordpress, tout le monde utilisent des builders pour être responsive. A l’époque, ce n’était pas vraiment le cas.

Si je me souviens bien, tu t’es retourné plus vers le développement applicatif par la suite ?

On avait déjà commencé un peu d’applicatif pour de la gestion d’événementielle qui était super bien, mais l’approche Business était (en mode) « je construis une fois le produit pendant 6 mois et après j’y touche plus » donc le problème, c’est que sur un produit ça ne marche pas trop.

J’ai ensuite intégré une équipe en tant qu’UX Designer, comme il n’y avait pas beaucoup de développeurs, j’aidais aussi sur d’autres sujets.

J’ai pu participer à un projet intéressant sur des widgets pour les sites d’e-commerce. Ces widgets sont du javascript et avant que j’arrive, il était assez lourd. Avec un développeur, on a travaillé pour enlever le maximum de code au possible. L’objectif est d’avoir quelque chose qui se charge rapidement sur le site des clients.

On a enlevé toute la notion d’image pour tout faire en CSS. Que tout soit configurable, mais que ce soit ultra léger pour éviter d’avoir à charger 400 images.

Ensuite je suis passé vers de l’applicatif métier. Là le poids de l’application a moins d’impact parce qu’une fois que je l’ai chargé, c’est bon. Par contre, pour la suite de la navigation cela nécessite de fluidifier et d’unifier l’expérience sur toutes les interfaces.

On a créé un design system, c’est une bibliothèque de composants et de design pattern (Note: patron de conception) prêt à l’emploi pour être utilisé par l’équipe de développement (comme des briques Lego). Cela permet d’avoir une navigation cohérente et même de pousser davantage le curseur sur l’accessibilité de l’application.

Enfin, je suis maintenant un des fondateurs du Bear studio (un studio de développement). On a créé des starters pour mieux démarrer les projets avec les bonnes pratiques. On a créé un starter pour le web, pour les applications mobiles et aussi pour les designers sous Figma.

Note
Plus d’information sur Start UI, le starter dont parle Ivan
  • https://github.com/BearStudio/start-ui-web

  • https://github.com/BearStudio/start-ui-native

  • https://www.figma.com/community/file/1025698982013308087

    Peux-tu peux nous décrire Figma ?

    C’est un logiciel de design qui permet de faire principalement de la conception d’interface. Il y a 10 ans, on utilisait Photoshop pour faire la même chose. Là, c’est sur le navigateur, sur toutes les plateformes, en mode collaboratif. C’est pour moi l’outil le plus poussé dans sa catégorie.

    Ce retour à 100% au Bear Studio, ça marque un retour au mobile?

    Chez Spread il y a toujours été question de mobile pour l’affichage des widgets. Chez Saagie ca l’était beaucoup moins car c’était un outil dédié à du travail sur ordinateur. L’application fonctionne sur mobile mais ce n’était pas du "Mobile first". On parle souvent de mobile mais c’est plutôt responsive qu’il faut utiliser : s’adapter à toutes tailles d’écrans : mobile, tablette, écran d’ordinateur, un MacBook 13 pouces…​

Ensuite ce qu’il faut réfléchir, c’est est-ce que l’usage de l’application mobile est le premier usage dans tel cas il faut construire les interfaces dédiées à cette utilisation, cela peut être coûteux mais nécessaire. Si par contre c’est un usage secondaire de consultation, car je peux me connecter techniquement depuis mon mobile, il faut faire que cela fonctionne et que l’utilisateur puisse au moins consulter et faire des actions simples.

A Webvert quand on a fait le diagnostic des sites web qui étaient produits par le Bear Studio et notamment le site du Bear Studio, on a toujours de très bons scores, de très bons niveaux d’éco-conception. Est-ce que vous avez une approche d’éco-conception ?

Je ne sais pas s’il y’a une approche d’éco-conception en fait, il y a une approche de bonnes pratiques. Par exemple, dès que l’on veut du référencement, on devrait faire de l’éco-conception. Le référencement est totalement lié au fait que ça charge vite pour l’expérience utilisateur. Plus ça va charger vite et plus ça va être simple.

Je me rappellerai toujours au tout début de ma carrière. Il y avait des boutons avec des icônes. Les icônes étaient fait en PNG. Quand on passait au-dessus (hover) du bouton pour survoler, l’icône changeait. On chargeait donc un autre PNG. Sauf que le problème, c’est qu’avec le réseau, le temps que la 2ème icône s’affiche, il y a un moment l’icône disparaissait et puis réapparaissait. Donc ça en termes d’expérience utilisateur, c’est horrible et en plus ça coûte 2 téléchargements d’images, 2 appels de réseau.

Pour éviter cela, on faisait des sprites. C’est-à-dire qu’on chargeait une fois une image avec toutes les choses. L’avantage, c’est que c’était moins coûteux. Pour l’expérience utilisateur, c’était plus rapide. Parce que quand je passais en hover, j’avais déjà mon image. L’expérience utilisateur était améliorée. En plus je gagnais aussi en poids parce que je pouvais optimiser une seule et unique image. Par contre en terme de maintenance, quand il fallait rajouter des images cela commençait à être galère.

Ensuite sont arrivées des fonts (polices de caractère) avec des jeux d’icônes comme font awesome. C’était révolutionnaire parce que ça permettait d’avoir des icônes vectorielles qu’on peut changer juste en changeant la taille de police et en changeant la couleur de la police. Sauf qu’au final on chargeait une police énorme pour utiliser au final 20 icônes…​ Au pire une font de 600 ko pour afficher 3 icônes. Je ne vais pas infliger de charger 600Ko en 3G pour avoir 2 icônes sur mon site. De plus cela provoque des problèmes d’accessibilité parce que ça reste une fonte donc ça reste des caractères que le lecteur d’écran essaie de lire.

Enfin, il y a eu les SVG inline qui permettaient directement de mettre le code, comme du HTML, directement dans la chose. Donc même plus besoin de télécharger une ressource externe au chargement HTML, j’ai directement les icônes qu’il faut au premier affichage de la page. Inconvénient, si j’utilise 4000 fois la même icône, je me trouve avec 4000 fois le petit bout de code (le cas est peu fréquent). L’avantage c’est que c’est déjà dans mon HTML, même si vous avez du délai dans le réseau, dès le début, l’affichage est le plus complet possible.

Ton axe, ta priorité, ce n’est pas l’éco-conception, c’est vraiment le parcours utilisateur ?

Mon job, aujourd’hui, au Bear Studio, c’est UX designer. L’idée c’est que l’usage soit le plus agréable possible donc ça veut dire que quand je charge quelque chose, je ne charge pas un truc pour rien. Je n’attends pas 3h. Pour moi, l’éco-conception c’est obligatoire si on veut optimiser l’expérience utilisateur, optimiser le SEO, optimiser les coûts.

Comment pourrais- tu définir l’UX, expérience utilisateur pour ton métier, à des personnes qui ne sont pas dans l’informatique ?

Mon job, c’est de faire en sorte, si possible, que l’utilisateur final (donc pas forcément le client) puisse avoir une expérience fluide et agréable qui correspond à son attente.

Par rapport à ce qu’on attend donc pour un site internet type site vitrine, c’est je suis dans le métro et on m’a parlé de tel sujet, je le recherche et je le trouve rapidement sur Google, je clique dessus, j’ai l’information et je parcours rapidement jusqu’à l’objectif final.

Mon objectif c’est de fluidifier tout ça, que ça soit simple à utiliser. En prenant des outils, des pratiques, de l’ergonomie, le développement, le business, en essayant d’orienter les choses pour que ça soit plus utilisable. Je dirais même que si on peut ne rien développer et que ça optimise l’expérience utilisateur, c’est mieux.

Souvent on dit que la meilleure éco-conception, c’est de ne pas faire quelque chose qui ne va pas servir. Est-ce que toi, dans ton rôle que tu as au Bear Studio, auprès des développeurs, auprès des clients, auprès du business, tu interviens là-dessus ?

Oui parce que moi, mon premier job, si ce n’est pas utile, je pense que je peux le supprimer. Ça fait optimiser l’expérience utilisateur, parce que cela ne surcharge pas d’une option inutile, que cela fait aussi optimiser le temps de développement parce que c’est zéro développement, ça fait optimiser le temps des bugs parce qu’il y a zéro bug. Mon premier objectif c’est, si ce n’est pas utile, est ce qu’on peut ne pas le mettre ?

J’ai vu une conférence l’autre jour à Codeurs en Seine sur l’éco-conception. Il y a juste un point qui m’a dérangé dans un exemple. Pour télécharger un podcast, il y avait 2 options, basse qualité ou haute qualité. Pour moi, c’est une mauvaise approche aussi bien en UX que en éco-conception. La solution serait de retirer la haute qualité et de mettre télécharger. C’est bien dans le monde parfait, mais je trouve qu’en terme d’expérience, c’est pas forcément la meilleure stratégie. Il y a peut-être des personnes avec du matériel dédié, mais globalement en tant qu’utilisateur je me pose même pas de question, je veux pas de la basse qualité. J’aurais juste transformé en disant « télécharger l’épisode » ou « qualité audiophile ». Puis quand je clic dessus, il y a quelque chose qui me dit « est-ce que vous allez voir la différence si vous n’avez pas le matériel adapté » et dans ce cas je télécharge l’épisode en qualité normale.

Tout à l’heure, tu disais que tu embêtais tes équipes de développement sur des bonnes pratiques. C’est quoi les règles que tu recommandes sur un site web ?

Sur un site web globalement, c’est tout ce que l’on peut optimiser (Note : pour avoir travaillé avec Ivan, on parle ici du moindre détail).

Il n’y a pas de débat c’est compresser et optimiser toutes les ressources.

Pour les parties à débats il y a l’utilisation des frameworks : certains vont conseiller de partir sans framework (HTML, CSS, Vanilla Javascript (i.e. javascript sans utilisation de framework)). Le problème est que ce type de projet est souvent fait par des juniors. Au bout d’un moment, pour aller plus vite, il rajoute bootstrap et l’utilise à 5% de ses fonctionnalités et il n’a pas forcément mis le socle pour minifier le javascript, le css. Enfin il rajoute les images à la va vite. A la fin, on se retrouve avec un site avec des performances horribles (mais il n’y a "presque" pas de framework).

De l’autre coté en utilisant Next.js, il y a déjà tout le socle d’optimisation. Automatiquement, les performances vont prendre un coût de boost pour les utilisateurs. Même du coté des core vitals.

Tu as parlé de core vitals. Est-ce que tu peux expliquer ce que c’est?

Ce sont des indicateurs de performance qui permettent de déterminer si on est plutôt dans les bonnes pratiques ou dans les mauvaises pratiques. Actuellement, Google l’utilise pour évaluer une page en navigation mobile et affiner le positionnement dans son moteur de recherche.

C’est comme les outils comme Lighthouse, vous avez une analyse automatique, ce n’est pas magique cela vous permet de savoir à quel niveau vous êtes dans les bonnes pratiques.

On a parlé des sites web. Quand on passe sur les applications web qui épuisent votre cœur de métier au Bear Studio, c’est quoi les bonnes pratiques que tu donnes à tes équipes ?

Bonnes pratiques, ça part toujours de la même chose, les outils. Par exemple, on utilise beaucoup une librairie qui s’appelle ChakraUI. C’est une librairie d’interface pour faire l’interface qui va permettre deux choses: 1/ de mettre le style uniquement de ce qui a besoin, donc il n’a pas chargé plein de choses pour rien, 2/ qui a tous les composants qui sont prévus avec de l’accessibilité. Cela force les bonnes pratiques. C’est à dire que si jamais je mets un menu, et bien, un développeur va réinventer la roue pour faire son menu. Celui ca va sans doute être mal accessible.

Pour optimiser une application, pour moi, on n’est plus sur le temps de chargement initial. On va charger pas mal de librairies pour fluidifier déjà pour le temps de développement. Les attentes dans une application moderne ne vont pas être les mêmes que sur un site web. Sur un site web, si on a peu d’interactivité, c’est pas très grave. Par contre, sur une application, on va s’attendre à énormément d’interactivité. Le javascript même minifié peut vite monter à 1Mo. Par contre sur des applications qui sont utilisées au quotidien, avec un cache bien configuré, le premier usage correspond à l’installation d’une application, tous les prochaines utilisations seront à affichage instantanées (sans nouveau chargement des 1Mo).

Est-ce que c’est un travail sur les API côté back end, pour réduire la taille de ce qu’ils vous envoient ? Par exemple, ils vous envoient tout ça de données et vous affichez que 2 lignes à l’écran ?

Alors cela va dépendre, si c’est nous qui faisons le backend/l’API ou pas. Si c’est une API qui va être utilisée de façon externe donc qui va être exposée aux clients qui peuvent utiliser un peu comme ils veulent, on va essayer de pas trop optimiser…​ malheureusement, pour ne pas bloquer les autres usages. C’est là où GraphQL, qui est un autre format d’API, va pouvoir aider. En fait, c’est la personne dans l’application web ou dans le site qui va dire, je veux ces informations-là, et du coup le serveur renvoie uniquement ce qu’il y a besoin.

Si tu devais conseiller une équipe pour commencer dans l’éco-conception, dans un axe d’expérience utilisateur ? Tu leur conseillerais de commencer par quoi ?

Le premier truc de site web, ce sont les outils. Les technologies pour être sûr d’avoir les bonnes performances. Next.js c’est controversé sur la partie usage CPU car cela demande un peu de javascript. Moi je suis parti sur un écosystème qui va favoriser les bonnes pratiques type Next.js, même si ça peut paraître contre intuitif. Car je vais avoir la main sur des choses de façon très granulaire mais en même temps les défauts sont vraiment optimisés. Je conseille aujourd’hui, même si je préférerais que Chakra soit un peu moins coûteux à l’exécution pour avoir des choses facilement utilisables mais qui va envoyer très peu de CSS à l’utilisateur final.

Ta conclusion pour faire de l’éco-conception, c’est formez-vous au CSS ?

Oui, si vous faites un site vitrine. Cela va éviter de faire plein de choses qui sont juste faisables en faisant 2 lignes de CSS qui vont remplacer 40 lignes de javascript.

Non, si vous faites une application web. Ma préconisation c’est d’avoir un environnement de « pré-production ». Si je teste depuis ma machine en local je verrais moins de chose à optimiser que sur un environnement réel, sur une préproduction, je vais aussi pouvoir lancer des analyses externes comme Lighthouse, tester des choses sans casser la production et me rendre compte des améliorations à faire.

Merci Ivan

Propos recueillis par Eva Giffard et Youen Chéné