Deez is la tech — Épisode 2 — L’accessibilité numérique

paulinem 66 min de lecture

This post is written in French exclusively as it accompanies the release of the second episode of “Deez is la tech”, a brand new podcast created by Deezer’s Product & Tech teams — in French only for now. Don’t worry though, we will keep publishing English content on deezer.io on a regular basis. As a matter of fact, you can check out our latest post about the story of Flow’s moods, or how Deezer’s recommendation team built an emotional AI!

Le deuxième épisode de Deez is la tech, un nouveau podcast créé, animé et réalisé par des membres de la division Product & Tech de Deezer, est maintenant disponible !

Deez is la tech propose d’aborder des sujets relatifs aux mondes du streaming musical et de la “tech” au sens large (incluant développement, produit, design, qualité, data, recherche, etc.), et d’explorer les coulisses de certaines des fonctionnalités phares de Deezer. Le tout à l’occasion de discussions entre collègues et pairs, en toute décontraction, mêlant partage d’expériences, bonnes pratiques et réflexions sur les évolutions possibles du secteur.

Un nouvel épisode est publié chaque premier mercredi du mois sur de nombreuses plateformes d’écoute et un transcript est mis à disposition en parallèle sur notre blog deezer.io.

Après avoir parlé de diversité dans le monde de la tech dans le premier épisode, nos équipes ont choisi de parler d’accessibilité numérique dans cette deuxième émission. Découvrez-la dès maintenant !

Résumé

Loïc Doubinine (@ztec6) et Vincent Lepot (@neozibok) accueillent aujourd’hui Céline Rouquié (Product Design Lead — @CelineRouquie), Dorothée Doublet (Senior iOS Engineer — @dodmaxx) et Matthieu Nogueron (Front End Technical Expert) pour parler accessibilité des sites web et applications mobiles.

Si des normes et règles ont été définies aux niveau global et local pour inciter les entreprises à rendre leurs interfaces utilisables par des personnes en situation de handicap, un grand nombre d’applications ne sont pas encore entièrement accessibles. Qu’est-ce que l’accessibilité ? Quels efforts sont nécessaires pour rendre une application accessible ? Pourquoi est-ce important d’investir sur le sujet ? Comment sensibiliser et convaincre les développeurs et les entreprises de le prioriser davantage ? Autant de questions auxquelles nos invités apporteront des éléments de réponses, avant de nous partager leurs “Coups de coeur” en fin d’émission.

Transcript

Vincent [00:00:07] Bonjour et bienvenue dans Deez is La Tech, le podcast qui n’pète ni les plombs ni les crons ! Je m’appelle Vincent, je suis Tech Lead Back-End chez Deezer et aujourd’hui je suis en compagnie de Loïc, qui va coanimer l’épisode avec moi. Salut Loïc, comment vas-tu ?

Loïc [00:00:22] Ça va très bien. Moi aussi, développeur back-end à Deezer depuis pas mal d’années maintenant. On se retrouve donc aujourd’hui pour un nouvel épisode : on va parler accessibilité dans le numérique.

Vincent [00:00:40] Un milliard, près d’une personne sur huit. C’est selon l’Organisation Mondiale de la Santé, en décembre 2020, le nombre de personnes touchées dans le monde par une forme de handicap. Et ce chiffre augmente. Ces handicaps peuvent être visuels, auditifs, moteurs, cognitifs… Le monde de la tech ne devrait donc pas ignorer cette part grandissante de la population pour ne pas l’exclure d’un monde de plus en plus tourné vers le numérique. Et d’ailleurs, depuis quelques années maintenant, le monde du Web, via le W3C (World Wide Web Consortium), réfléchit à ces problématiques au travers d’une initiative, le WAI, pour Web Accessibility Initiative. Ce groupe de travail vise à améliorer les conditions d’utilisation pour les personnes en situation de handicap. En sont sorties un certain nombre de normes nommées WCAG ou “wékague” pour les intimes (pour Web Content Accessibility Guidelines). L’apparition des objets connectés, et particulièrement le succès des smartphones et des tablettes, a amené également les constructeurs et les développeurs sur ces plateformes à réfléchir à des moyens de prendre en compte ces usages pour faire bénéficier tout le monde de la meilleure expérience possible — grâce au voice-over pour les malvoyants par exemple. D’un point de vue réglementaire, certains pays comme la France ont adopté des règles dont le but est d’améliorer la qualité d’accessibilité au numérique. C’est notamment l’objet du Référentiel Général d’Amélioration de l’Accessibilité, anciennement Référentiel Général d’Accessibilité pour les Administrations. Bref, “RGAA” toujours. Cette liste de règles basée sur les WCAG a eu pour vocation au départ de définir un cadre contraignant pour que les sites web des administrations puissent être utilisés par le plus grand nombre. Depuis, ce référentiel est également devenu contraignant pour les entreprises avec un chiffre d’affaires au-delà de 250 millions d’euros. La démocratisation de l’Internet, c’est quelque chose de relativement récent : on parle de la fin des années 90. Et les premières normes WCAG sont sorties en 1999. C’est donc un sujet récent, mais intégré très rapidement dans le web. Cependant, bon nombre d’applications ne sont pas encore complètement accessibles. Qu’est-ce que cela représente comme travail ? Comment gérer au mieux ces notions d’accessibilité ? Quel est l’état de l’art ? Quels sont les pièges à éviter pour ne pas rendre son application inutilisable par une partie de la population ? Voilà le sujet de ce nouvel épisode de Deez is La Tech.

Loïc [00:02:43] Et pour en parler avec nous aujourd’hui, on a trois invités. Céline, qui est avec nous à travers la technologie Zoom.

Céline [00:02:51] Bonjour.

Loïc [00:02:51] Est-ce que tu peux te présenter ?

Céline [00:02:53] Donc Céline, enchantée ! Je travaille dans le département “Innovation & Diversification” et je suis Product Designer pour cette équipe. J’ai notamment travaillé sur une application de livres audio pour laquelle on a fait un gros travail d’accessibilité dont je vous parlerai tout à l’heure.

Loïc [00:03:08] Merci ! Avec nous sur site, nous avons donc Dorothée aussi.

Dorothée [00:03:12] Bonjour.

Loïc [00:03:13] Bonjour Dorothée.

Dorothée [00:03:13] Je travaille pour la startup UP et je suis développeur iOS (ndlr: les équipes Product & Tech de Deezer sont organisées en “startups” et “UP” signifie “User Platform”).

Loïc [00:03:19] Et à côté, nous avons Matthieu.

Matthieu [00:03:21] Oui, bonjour. Moi, je travaille pour la startup Content et je suis Lead Front-End.

Loïc [00:03:28] Donc nous allons commencer par une question — on va faire le tour de table : qu’est-ce qui vous a amenés à vous intéresser à ce sujet de l’accessibilité, à Deezer ou en général ? Je vais commencer par la personne la plus proche, Matthieu par exemple.

Matthieu [00:03:45] Pour moi, l’accessibilité, ça a commencé avec un projet étudiant, que j’ai donc fait en école d’ingénieur et qui consistait à faire de la reconnaissance et de la transcription de la langue des signes pour permettre à des personnes qui signent et à des personnes qui ne connaissent pas la langue des signes de pouvoir communiquer entre elles et de comprendre la langue des signes. J’ai ensuite enchaîné sur un stage dans une entreprise. Cette entreprise faisait de l’accessibilité son fer de lance avec un système de calcul d’itinéraire pour les personnes à mobilité réduite, des personnes ayant des handicaps moteurs, des handicaps cognitifs ou des personnes ayant des déficiences visuelles. Parce que ces différents types de handicap donnent lieu à différents types de calculs d’itinéraire, comme par exemple : signaler à une personne étant dans un fauteuil roulant qu’il y a des zones moins accessibles que d’autres avec du gravier par exemple ou des dévers, ou pour des personnes ayant des déficiences visuelles, signaler la présence de bandes d’éveil à la vigilance qui vont permettre de signaler un passage piéton. Voilà, c’est comme ça que l’accessibilité est un peu rentrée dans mon cursus professionnel.

Loïc [00:04:55] Très bien, merci. Et toi, Dorothée ?

Dorothée [00:04:59] De mon côté, je pense que c’est un sujet qui me touche depuis très longtemps. Quand j’avais 9–10 ans, je suis partie en Angleterre vivre un an au milieu des petits Anglais, dans une boarding school, et j’ai appris l’anglais sur le tas. Et pour la première fois, j’avais une différence qui faisait que mon intégration n’était pas très facile. Elle s’est très bien passée cette année mais du coup, j’ai gardé l’idée que pour moi, c’est insupportable qu’on soit mis à l’écart à cause d’une différence. Après, aujourd’hui, j’ai une personne très proche de moi qui est en situation de handicap. Donc forcément, c’est un sujet qui me touche d’autant plus. Et j’ai eu la chance, dans mon cursus professionnel, de travailler pour le groupe SNCF et de faire en sorte qu’une application pour les personnes qui avaient un handicap visuel puisse fonctionner pour elles. L’idée, c’était qu’on puisse accueillir les personnes aveugles à la sortie du train et les guider dans la gare. Donc j’ai écrit le code pour ça et il y a une personne aveugle qui a testé l’application. Et là, ça a été un choc parce qu’entre les idées que j’avais et l’usage, je me suis rendu compte qu’il y avait un énorme chemin.

Loïc [00:06:19] J’ai l’impression qu’il y a beaucoup de thématiques autour du transport.

Vincent [00:06:23] Oui, surtout que c’est typiquement le genre d’applications où il y a souvent ce besoin d’accessibilité qui apparaît. Pour avoir travaillé moi aussi un peu dans les transports, plus dans le transport public, dans des choses un peu plus classiques, c’est vrai que c’est un point important dans les applications qu’on délivre parce qu’il y a justement la contrainte du RGAA de devoir rendre cette application complètement accessible. C’est quelque chose qui fait vraiment partie de l’ADN de ce genre de trucs.

Loïc [00:06:50] Ok. Et Céline, comment l’accessibilité est-elle devenue un fer de lance pour toi ?

Céline [00:06:58] Pas pendant mes études, malheureusement. J’aurais bien aimé être sensibilisée au sujet dès mon diplôme mais ça n’a pas été le cas. Et pas non plus dans ma première partie de carrière. En fait, ça a été une révélation plutôt chez Deezer puisque pendant ma première semaine, au moment où j’ai été onboardée chez Deezer il y a deux ans, ma première mission a été d’auditer l’application mobile Deezer sur iOS et Android d’un point de vue de l’accessibilité, pour faire un petit peu un état de l’art de ce qui existait. Bon, le constat n’était pas très bon. Les typographies, par exemple, étaient bloquées. On ne pouvait pas les grossir. Il n’y avait pas d’audiodescription, ou très peu, ce qui rendait le produit inutilisable pour des aveugles. Et puis je n’ai même pas audité la partie pour éventuellement les malentendants — il y a des choses qui peuvent se faire sur des applications là-dessus mais je me suis vraiment concentrée sur les handicaps visuels. À la suite de ça, mon équipe a travaillé sur une application pour les livres audio, ce qui, logiquement, nous a aussi tourné vers ce public de malvoyants et d’aveugles parce que c’est l’un des accès à la littérature privilégiés pour eux. Alors, ce n’est pas l’unique accès parce que le braille reste obligatoire pour eux pour au moins apprendre l’orthographe. Et puis on a fait des tests utilisateurs et effectivement, comme Dorothée, grosse prise de conscience au moment des tests utilisateurs. On se faisait une certaine idée de la manière dont ils pouvaient utiliser un smartphone, qui a un petit peu volé en éclats ! Donc on a appris énormément de choses à ce moment-là et on a appris sur le tas. Puis on s’est amélioré et on a refait des tests derrière. Voilà, ça a été une belle expérience par l’erreur !

Loïc [00:08:41] Et vous auriez des exemples, comme ça, de révélations suite à des tests d’utilisateurs ?

Dorothée [00:08:48] De mon côté par exemple, très concrètement, quand on code, on a toujours envie de mettre le maximum de détails parce qu’on se dit que si on ne voit rien sur l’écran, on veut vraiment avoir le maximum de choses. Mais quand on voit un aveugle utiliser un téléphone, en fait, il va très très très vite. C’est-à-dire que la première fois, il va parcourir l’écran et après, enregistrer comment l’écran est constitué. Et il va aller très très très vite. Donc si on a des textes obligatoires, ça va plutôt le freiner et empêcher une lecture fluide de l’application. Donc la vitesse d’utilisation… Moi, j’étais complètement bluffée ! C’est vraiment autre chose.

Céline [00:09:36] Moi, du coup, je vais rebondir sur la vitesse. Parce que, par exemple, sur le VoiceOver ou le TalkBack, nous, on l’utilisait en vitesse par défaut. Et puis en fait, le premier utilisateur aveugle qu’on a eu a pris le téléphone et a dit “je suis désolé, il faut que je change le paramètre parce que ça va vraiment trop lentement pour moi”. Il a poussé le VoiceOver quasiment au maximum et c’était super dur à suivre pour nous parce qu’on n’était pas du tout habitué. Mais lui, il était à fond. Et il y avait un deuxième détail qui aurait dû nous paraître évident : en fait, ils ont les téléphones avec affichage noir. Ça ne sert à rien pour eux de bouffer de la batterie pour afficher un écran qu’ils ne voient pas donc quand ils testent une application, ils ont un téléphone noir sans image dessus.

Dorothée [00:10:21] Je précise juste que le VoiceOver, du coup, c’est vraiment la voix — sur iOS en tout cas, je ne sais pas sur les autres plateformes — qui va permettre d’avoir les éléments visuels en audio.

Loïc [00:10:34] Ça va décrire l’interface, c’est ça ?

Dorothée [00:10:35] Exactement.

Céline [00:10:37] Ça va lire les textes disponibles sur l’écran. Et ça va aussi lire les audiodescriptions qui sont prévues et implémentées par les développeurs pour, par exemple, rendre compréhensible un icône qui autrement ne serait pas lu, ou une image.

Matthieu [00:10:49] Effectivement, de façon plus générale, on appelle ça un “lecteur d’écran”. Je crois que sur Windows, ça s’appelle justement comme ça.

Vincent [00:10:55] Et toi, par exemple, Matthieu ? Est-ce qu’il y a des choses qui t’ont surpris dans tes premières occasions de travailler sur ce genre de sujet ? Peut-être que tu as déjà fait des tests utilisateurs avec des gens qui étaient en situation de handicap aussi ?

Matthieu [00:11:08] Alors oui, pour moi, ça a été exactement la même situation : voir des personnes en situation de handicap visuel parce que c’est la chose qui change le plus quand on fait de l’accessibilité. C’est une utilisation complètement différente d’une application. Et c’est vrai que ça a été un choc de voir la vitesse à laquelle une personne aveugle ou malvoyante navigue dans l’application. Parce que oui, nous, en tant que développeur, on fait attention à tous les petits détails…et ça ne va pas à la même vitesse !

Vincent [00:11:37] Du coup, dans votre travail de tous les jours, je ne sais pas si vous avez à cœur à l’heure actuelle de travailler sur l’accessibilité — je sais que Céline, oui, puisque sur l’application Audiobooks, ça a été un gros sujet — Dorothée, Mathieu, je ne sais pas si vous continuez à travailler sur l’accessibilité des applications, chacun sur vos plateformes ? Comment essayez-vous de garder ça en tête ? Est-ce qu’il y a des étapes importantes dans le cycle de développement qu’il faut avoir absolument pris en compte pour que le développement se fasse bien ?

Dorothée [00:12:06] Moi, j’essaye toujours de faire avancer ce sujet. J’ai eu la chance de discuter avec un ingénieur Apple pendant une demi-heure — deux même — et on a fait une sorte d’audit de l’application Deezer pour voir les points qui péchaient. C’était super intéressant parce que ça nous a permis d’identifier des tâches prioritaires. Donc je les note et j’essaie d’être attentive, quand je fais des reviews de tickets d’autres développeurs par exemple, à ces utilisations-là. Et je teste régulièrement VoiceOver. Je garde ça en tête parce qu’en fait ce que j’ai découvert, c’est que l’accessibilité, c’est clairement du travail — il ne faut pas le nier, c’est évidemment un effort — mais plus on s’y prend tôt, plus on pense à l’accessibilité tôt, même au niveau des spécifications, plus le code est propre et plus on gagne du temps au final.

Matthieu [00:13:08] De mon côté, c’est quelque chose que j’ai aussi à l’esprit, dans la tête, dans un coin de la tête. Malheureusement, ce n’est pas quelque chose sur lequel je peux mettre un peu plus d’effort à l’heure actuelle. Mais effectivement, je pense que c’est quelque chose qui doit être pris en compte dès les phases de spécifications parce qu’il y a une façon de naviguer qui peut être différente de façon visuelle avec certains principes d’accessibilité.

Dorothée [00:13:31] Et l’avantage de travailler sur ces sujets d’accessibilité, c’est que je me suis rendue compte que ça éclaboussait un peu partout. Non seulement, au final, ça apporte une meilleure expérience aux utilisateurs — et parfois pas seulement les personnes en situation de handicap — mais aussi du côté d’iOS, on a des identifiants d’accessibilité et ce sont ces identifiants-là qui vont être utilisés pour faire des tests d’intégration par exemple. Donc au final, si on porte un effort particulier sur l’accessibilité, ça va aider à faire des tests et avoir une application qui, en prod, va moins crasher par exemple.

Vincent [00:14:12] D’accord. Céline ?

Céline [00:14:14] Je rajouterais un petit détail sur des manières dans les process qui peuvent aider à la prise en compte quotidienne de l’accessibilité. Très concrètement, dans l’outil de ticketing qu’on utilise — qui est JIRA — on a demandé l’ajout d’un champ qui s’appelle “accessibility requirement”, dans lequel on met systématiquement les liens vers le tableau de la copy, qui va rediriger vers la bonne audiodescription pour la bonne feature, en expliquant par exemple que sur le component “card” qui va être développé, on va jusqu’à X lignes et au-delà, on crop par exemple. Donner ce genre de règles en disant que, de toute manière, ça doit réagir au grossissement de texte, etc. Bref, on fait des spécifications accessibilité dédiées.

Vincent [00:14:59] Dès le design finalement. Dès le design de la feature, on commence à réfléchir à ce genre d’informations.

Céline [00:15:06] Oui. Ça peut aller, par exemple, de privilégier le fait de mettre des boutons les uns sous les autres plutôt que les uns à côté des autres pour qu’au moment ou les textes grossissent, ça ne pose pas de problème. Ça va être des choses comme ça.

Loïc [00:15:18] Du coup, vous intégrez ces règles dans votre “definition of done”, donc dans la définition de réalisation de vos features et de vos tickets ?

Céline [00:15:29] Tout à fait. Par exemple, si le lecteur d’écran ne peut pas lire un élément, le ticket est retoqué. Il repart en dév.

Loïc [00:15:45] Comment avez-vous fait pour justifier tout ce temps, tout ce coût lié à l’intégration de l’accessibilité qui, au début, peut paraître peut-être supérieur au retour sur investissement qu’on peut imaginer ? Comment faites-vous pour dire “c’est important de prendre en compte cette partie de l’accessibilité” et faire des choix en disant que, peut-être, cette partie-là, on va moins la prendre en compte ?

Dorothée [00:16:09] Je trouve que c’est toujours un combat. Encore aujourd’hui, j’ai discuté d’un ticket sur l’accessibilité et ça prend un peu de temps. On doit se justifier toujours là-dessus, mais rien n’est perdu. Je pense que plus on en parle déjà, plus ça rentre un peu dans les esprits que c’est important. Et j’étais surprise de voir que quand on pense accessibilité, on doit faire un code qui est modulable et qui doit vraiment fonctionner dans toutes les situations. Donc ça signifie concrètement que le code va être plus propre et qu’on ne va pas mettre, par exemple, des valeurs en dur qui, au moindre changement de situation, ne vont pas correspondre à ce qu’on attend. Au final, le code est plus propre et l’application est plus stable. Ça, c’est ce que j’essaye de faire passer comme message.

Vincent [00:17:07] Je vais poser une question très naïve. Je suis dév back-end, donc les questions d’accessibilité ne me concernent pas vraiment au quotidien, en tout cas pas dans le code que je produis — il y a des parties où l’on essaie de prendre ça en compte. Finalement, quand on a une interface qui est accessible, est-ce que ça ne rend pas aussi service aux “valides”, en rendant l’interface peut-être plus simple à utiliser ? Est-ce que ça simplifie des parcours ? Est-ce que ça permet plus de confort pour l’utilisateur ?

Matthieu [00:17:39] Alors je pense qu’on a une définition de l’accessibilité où l’on voit très souvent l’accessibilité comme étant la mise en œuvre de techniques pour rendre une interface utilisable par des personnes qui ont un handicap. Je pense qu’il faudrait complètement retirer cette partie “handicap” de la définition et dire que l’accessibilité, c’est pour tous. Ce n’est pas qu’une personne qui a un handicap va pouvoir utiliser l’interface, c’est que tout le monde va pouvoir utiliser l’interface, peu importe sa situation, qu’elle ait un handicap ou non. Parce qu’à tout moment de notre vie, on peut se retrouver dans des situations de handicap — alors peut-être pas un handicap lourd. Si on prend la situation d’une personne qui est atteinte de surdité, on peut se retrouver dans une situation de handicap un peu plus léger, qui peut être liée, par exemple, à une maladie. On pourra citer, par exemple, une personne qui va avoir une otite. Cette personne va avoir une diminution de ses capacités auditives donc l’accessibilité va être quelque chose qui va lui permettre de mieux comprendre les interfaces et de continuer à comprendre les interfaces malgré la maladie. Quelque chose à laquelle on peut avoir affaire quasiment tous les jours, je pense : étant à Paris, on prend les transports en commun, on prend le métro, on se retrouve dans des environnements qui sont assez bruyants. C’est une sorte de handicap parce que si on regarde une vidéo, on ne va pas être capable d’entendre le son qu’il y a dans la vidéo. Pourtant, on veut quand même comprendre ce qu’il y a dans la vidéo. Donc un principe d’accessibilité qui, je pense, est assez connu par tout le monde maintenant avec Facebook et autre, c’est le principe de sous-titrage. Quand on a une vidéo, on va rajouter des sous-titres pour que, même si l’on n’a pas la capacité d’entendre le son, on puisse continuer de comprendre la vidéo. Et ça, je pense que ça touche beaucoup de personnes. Quand on scroll notre mur Facebook, on voit toutes ces vidéos qui ont le sous-titrage. Donc ça, c’est un principe d’accessibilité qui est mis au profit de tout le monde. Et la plupart des principes d’accessibilité vont pouvoir bénéficier à tous, et non pas qu’aux personnes qui sont en situation de handicap.

Céline [00:19:39] On pourrait aussi rajouter des questions de sémantique. Par exemple, quand on rédige une interface avec beaucoup d’anglicismes, c’est mettre des barrières à la compréhension à toutes les personnes qui ne maîtrisent pas l’anglais. Ça aussi, c’est l’accessibilité.

Dorothée [00:19:54] Ça touche vraiment à tout. Je suis entièrement d’accord avec ce qui vient d’être dit. Sur iOS, Apple met vraiment l’accent sur ce sujet-là et notamment dernièrement, ils ont développé ce qu’on appelle l’AssistiveTouch qui permet aux utilisateurs de la Watch de faire des actions sur leur montre en pinçant ou en serrant le point. Par exemple, en pinçant, on peut naviguer dans un menu, et en serrant le point, on sélectionne et on peut lancer une musique. Je trouve ça trop cool !

Vincent [00:20:25] C’est génial ! Je ne connaissais pas. Je trouve ça magique ! D’ailleurs, je me pose aussi la question : du coup, est-ce que maintenant ces critères-là commencent à rentrer dans les critères de validation d’applications par les deux grands stores — le Play Store et l’Apple Store ?

Dorothée [00:20:40] À ma connaissance, pas encore.

Céline [00:20:43] Mais par contre, c’est un risque aussi auquel on s’expose en conservant des applications qui ne sont pas accessibles parce qu’à un moment donné, les règles vont évoluer, que ce soit le cadre législatif de notre pays — par exemple la France, l’Europe ou celle des stores, qui sont, du coup, beaucoup plus contraignantes et beaucoup plus rapides à mettre en place.

Vincent [00:21:05] En préparant l’épisode, il y a quelque chose qui m’a frappé et je rebondis par rapport à ce que disait Dorothée tout à l’heure sur le fait qu’on a du mal à vendre le fait de travailler sur l’accessibilité au quotidien. Tout à l’heure, je le disais en intro, il y a un milliard de personnes qui sont en situation de handicap dans le monde. Et en fait, dans une des vidéos que j’ai regardées, ils disaient qu’au-delà de ce milliard de personnes — c’est un peu plus en réalité, c’est 1,3 milliard de mémoire — il y a aussi tout l’entourage qui est sensibilisé à ce genre de choses. Et en fait, ça représente pas loin de 3 milliards de personnes dans le monde. Donc ça veut dire que quelque part, on a pas loin de 10% des gens qui vont pouvoir utiliser notre application qui sont en situation de handicap. Est-ce qu’on ne peut pas utiliser ce genre d’argument pour dire : “ça représente quand même une part non négligeable de nos utilisateurs, est-ce que ça ne vaut vraiment pas le coup d’investir un peu dans l’accessibilité de nos applications ?”

Céline [00:21:55] Je vais rebondir là-dessus parce qu’on a eu des chiffres sur l’application Audiobooks by Deezer, puisqu’on a mis des trackers pour savoir combien de personnes utilisaient les modes “gros caractères” par exemple, ou les modes “assistants vocaux”. Et on a eu la surprise de constater qu’il y avait 20% de nos utilisateurs sur iOS qui utilisaient le mode “gros caractères”. Et le mode “gros caractères”, ce n’est pas juste augmenter d’une ou deux tailles. Les “gros caractères”, c’est à partir de la cinquième taille donc on est vraiment sur du gros texte. C’était un petit peu un choc, 20%, c’était beaucoup !

Vincent [00:22:26] Effectivement, ça peut être un bon argument. Alors c’est vrai qu’Audiobooks, on le disait tout à l’heure, c’est aussi un marché qui est orienté vers les personnes en situation de handicap, mais finalement, on pourrait se dire : “ça touche peut-être les gens en situation de handicap auditif et au final, ça touche aussi des gens qui ont peut-être un handicap visuel à gérer”.

Céline [00:22:46] Il faut se dire qu’un handicap visuel, ça peut être juste un problème de vue comme la myopie ou des choses qui sont très courantes. Et on en connaît tous, des personnes qui portent des lunettes !

Vincent [00:22:58] Il y en a, il y en a… Autour de cette table, il y en a !

Loïc [00:23:04] Je ne sais pas s’il y a des choses que vous, vous voudriez aborder concernant l’accessibilité ?

Matthieu [00:23:10] Alors oui, pour parler un peu des entreprises et pourquoi les entreprises, peut-être, ont plus de difficulté à voir les atouts de l’accessibilité. Je pense qu’il y a un risque de rentrer dans un cercle vicieux quand on a une application qui n’est pas accessible. Si on a une application, par exemple, et un utilisateur qui veut utiliser un lecteur d’écran, on peut se retrouver dans des situations où si l’application n’est pas accessible, on n’aura pas d’utilisateurs qui auront un besoin particulier d’accessibilité, et on n’aura pas non plus de retour. Donc si on ne fait pas attention à ça, je pense qu’il y a un très gros risque de ne pas voir le besoin. Même si le besoin est là, il serait caché par une mauvaise interface.

Dorothée [00:23:52] De mon côté, je parle d’expérience : à chaque fois que j’ai travaillé sur l’accessibilité, je me suis rendue compte à quel point il fallait être pragmatique sur ce sujet-là, c’est-à-dire ne vraiment pas chercher à faire la version parfaite, qui sera idéale, qui fonctionnera dans tous les cas. Mais c’est un sujet qu’on peut avancer par petits pas donc il ne faut pas hésiter à en faire un peu, parce que c’est toujours mieux que d’exclure ce sujet, de ne pas y penser. Juste, garder ce pragmatisme, et en fonction des opportunités, “tiens, je travaille sur tel composant et pourquoi pas rajouter de l’accessibilité, c’est très peu d’effort — allez hop, j’embarque ça dans le ticket”. Je pense que c’est la meilleure approche pour avancer.

Céline [00:24:41] Et de se dire aussi que, quand on commence un nouveau projet, mieux vaut l’intégrer dès le début parce que ça coûte toujours moins cher de le prendre en compte dès la conception, plutôt que d’avoir une application déjà live et de se dire : “Comment on la rend accessible ? Il y a du travail !”

Vincent [00:24:55] Oui, c’est un peu comme toutes ces choses, comme l’internationalisation, toutes ces notions-là qui sont du commun. Effectivement, si on ne les traite pas dès le départ, finalement, ça nous coûte plus cher.

Céline [00:25:07] Tout à fait.

Matthieu [00:25:08] Je vais peut-être rebondir sur ce qu’a dit Dorothée. Effectivement, quand on commence à faire de l’accessibilité à bas niveau et qu’on a un système qui est assez modulable, si on rend ces modules accessibles, on peut bénéficier de l’accessibilité à plus grande échelle dans le reste de l’application. Si on prend le principe d’un bouton par exemple, si on rend accessible un bouton — qui est, d’une certaine façon, naturellement accessible s’il est bien implémenté — ou alors par exemple un formulaire, et qu’on le réutilise dans l’application, on aura ce bouton qui sera accessible grâce à son implémentation. Donc je pense que c’est assez important, ça va avec une bonne façon de coder, d’implémenter les choses, de faire des briques qui sont modulables. Ces briques sont beaucoup plus simples à rendre accessibles. Et donc au final, de rendre l’intégralité du site plus accessible.

Dorothée [00:26:01] Complètement. C’était le sujet de ce matin, merci ! Exactement ! Je voulais juste insister sur un point, c’est que je travaille sur l’accessibilité et au final, c’est vraiment hyper enrichissant. Je ne sais pas si je vais réussir à vous convaincre mais en gros, dès que j’ai commencé à travailler sur l’accessibilité et tout ce qui est des problématiques de mise en page sur iOS, je me suis rendue compte que je n’avais pas vraiment compris comment le système marchait pour la mise en forme. J’arrivais à avoir le résultat que je souhaitais, mais peut-être un peu par chance. Et c’est en travaillant sur l’accessibilité, en travaillant sur un code qui marchait dans tous les cas, que j’ai vraiment dû comprendre au fond comment ça fonctionnait, quelle vue était mise en forme avant quelle autre, et la hiérarchie des vues. Donc, même au niveau technique, c’est un très beau voyage. Ça vaut vraiment le coup de mettre de l’effort dedans.

Loïc [00:26:58] Parce que les grands constructeurs — donc Google et Apple — ont pris en compte tous ces paramètres depuis pas mal d’années. L’un des trucs qui est frappant, notamment dans l’intro qu’a fait Vincent, c’est que beaucoup de standards, beaucoup des règles qu’on a sont là depuis très très longtemps. Surtout si on prend en compte depuis combien de temps on a de l’électronique tels des smartphones ou autres. En gros, depuis 2005 on a des smartphones. L’accessibilité date d’avant ça. Sur les smartphones, c’est intégré dans le système quasiment depuis le départ. Si on prend le cas d’Apple, c’est intégré dans MacOS depuis très très longtemps, depuis probablement avant les années 2000. Et en fait, ce sont des sujets qui ont déjà été traités depuis longtemps, qui ont déjà été, en partie, résolus. Je reviens sur le pragmatisme : rien n’est parfait, tous ces systèmes évoluent, il y a des nouvelles versions, des nouvelles mises à jour… L’accessibilité s’améliore avec le temps. Mais quand on voit, déjà, tout ce qui a été mis en place avant que, nous-mêmes, on ne commence à s’intéresser à ces sujets-là, ça montre qu’on a déjà beaucoup d’outils à notre disposition. Comme tu le dis en fait, il suffit d’aller les regarder et d’apprendre à les utiliser pour se rendre compte qu’il y a des gens très intelligents qui ont déjà réfléchi et résolu la majorité des problèmes sur les questions d’accessibilité. Il reste toujours à innover mais, au final, assez peu sur des objets du quotidien comme nos téléphones, notre site web, nos applications.

Matthieu [00:28:21] Dans le cas des sites web, finalement, si on utilise la bonne sémantique avec le bon type de balisage, on a de l’accessibilité gratuitement. Je vais prendre l’exemple des boutons parce que c’est un cas d’école pour lequel beaucoup de sites web font l’erreur : vous savez, ces “div” sur lesquels on met un événement qui va gérer un clic. Donc en clair, on fait un bouton avec une “div”. Ça, c’est quelque chose qui n’incorpore pas d’accessibilité. C’est quelque chose qui ne sera pas lu par, par exemple, un lecteur d’écran et qui sera complètement inutilisable d’une personne en situation de déficience visuelle. Et le simple fait d’utiliser un bouton, le tag “button”, va nous permettre d’avoir de l’accessibilité. Donc, comme tu dis, on a tellement de choses qui sont faites pour nous si on les utilise correctement, que l’accessibilité n’est pas quelque chose qui doit être très difficile à mettre en œuvre. C’est juste une des bonnes pratiques qui doivent être respectées, comme faire attention à la sémantique, l’utilisation de la sémantique HTML, quand on développe une application, un site web.

Loïc [00:29:31] J’ai vu des exemples de sites web — c’est souvent le cas dans des “sites vitrines”, vous savez, les sites web qu’on fabrique pour de l’événementiel ou pour un petit commerce. Souvent, je vois des sites comme ça qui sont très beaux, mais quand on commence à les ouvrir avec du voice-over, des lecteurs d’écran ou d’autres outils d’analyse de l’accessibilité, on se rend compte que c’est très beau pour les gens qui sont en parfaite capacité. Du coup, comment faire en sorte que même des sites comme ça — par exemple une boucherie qui va faire son site web — comment réussir à faire en sorte que même les contractants qui vont faire ces sites web les rendent accessibles ? Parce que souvent, ce qui va être mis en valeur, ça va être le côté exceptionnel, le côté joli : “Regardez mon site, il bouge dans tous les sens, c’est joli ! Regardez ma vache, elle passe dans le pâturage…” J’en passe et des meilleurs ! Alors qu’au final, quand quelqu’un va vouloir réellement accéder à l’information de la boucherie — je ne sais pas, des horaires par exemple, cette personne va arriver sur le site, va se retrouver face à ces jolies choses qu’elle ne pourra pas expérimenter, s’arrêtera et partira probablement.

Dorothée [00:30:35] Comme on vient de le dire, l’accessibilité, ce n’est pas forcément beaucoup d’efforts, c’est parfois juste utiliser les bons outils. Et franchement, mon expérience avec les développeurs m’a montré qu’il y a une vraie envie de s’améliorer sur ce sujet. Parce qu’on est tous là pour apporter une meilleure expérience à l’utilisateur, c’est ce qui nous anime en fait ! Il y a des développeurs qui viennent me voir en me disant “Hey Dorothée, tu ne veux pas faire une présentation ? Parce que j’ai vu que dans tes reviews tu en parles et moi je ne suis pas au courant de ce sujet, vas-y !” et qui poussent derrière. Donc je pense que c’est aussi de notre responsabilité de maintenir une code base qui est propre. Ça fait partie de notre boulot aussi de pousser sur ces sujets-là. Et il y a une vraie envie !

Céline [00:31:22] Plus qu’un manque de volonté, je pense que c’est surtout un manque d’information. Il y a un manque de formation à la fois des équipes — que ce soit des développeurs, des designers. Et tu parlais tout à l’heure des clients : comment faire pour que, quand tu t’adresses à un presta, il rentre ça dans son cahier des charges ? En fait, encore une fois, si d’un point de vue large de la population, on était mieux informé sur ce qu’est l’accessibilité, mieux formé au numérique, on pourrait aussi avoir des exigences plus pointues.

Matthieu [00:31:50] Oui, c’est quelque chose avec laquelle je suis assez d’accord. J’ai eu la chance, par mon parcours en école d’ingénieurs, d’avoir accès à un projet qui amenait de l’accessibilité. Malheureusement, je pense que je fais partie des quelques pourcents d’élèves ingénieurs qui ont eu la possibilité de toucher un peu de l’accessibilité. Et je pense que c’est quelque chose qui serait très utile de mettre dans un cursus d’écoles d’ingénieurs ou même pour un simple niveau bac +2, d’avoir un minimum de connaissances sur : qu’est-ce que l’accessibilité et pourquoi est-ce aussi important de travailler sur l’accessibilité pour tout type d’utilisateur ?

Loïc [00:32:33] À ranger à côté de l’apprentissage du développement en tant que tel.

Vincent [00:32:36] Même de manière générale en fait. J’ai même un exemple. Tout à l’heure, je plaisantais en disant “je suis dév back-end donc ça ne me concerne pas”. C’est un peu caricatural et j’ai notamment pris conscience assez récemment qu’en dév backend, on fabrique des API, on suit des metrics, on regarde du monitoring, etc. Et assez récemment quelqu’un, qui est juste à côté de moi en plus, m’a fait prendre conscience que les graphes qu’on sort sur des tableaux de bord ont besoin aussi d’être accessibles. C’est-à-dire que ce n’est pas le tout de faire des jolis graphes avec des jolies courbes, si les deux courbes ont la même couleur, pour quelqu’un qui est daltonien ou autre, ça ne lui parlera pas. C’est important aussi de le prendre en compte de manière générale sur toutes les actions qu’on fait.

Loïc [00:33:20] Oui, ça se voit beaucoup quand on voit des graphiques dans des présentations. Ou parfois il suffit d’utiliser Excel et de faire des graphes, et on se rend compte qu’en tant que daltonien, le bleu et rouge, les nuances ne sont pas forcément bien distinguées, alors que pourtant ce sont les couleurs par défaut sorties par le logiciel. Donc par défaut, le logiciel nous rend quelque chose qui n’est probablement pas accessible et souvent il suffit de très très peu pour pouvoir le rendre accessible. Si on prend le cas d’Excel, contrairement à Google Sheets par exemple, toutes les courbes ont des couleurs qui ne sont peut-être pas accessibles, mais par défaut elles ont des “points” toujours différents — des triangles, des carrés, des ronds — ce qui les rend de facto accessibles parce que c’est quelque chose qui est indépendant de la couleur. Pour les logiciels de graphes, par exemple, je pense que c’est quelque chose qui devrait être intégré dès le départ pour que par défaut, quand on crée un graphe, les couleurs qui sont utilisées soient différentiables, peu importe le type de daltonisme dont les gens peuvent souffrir. Voire de jouer carrément sur la forme. Dans l’exemple dont parle Vincent, il y avait des courbes en tirets, des courbes en pointillés, des grosseurs différentes qui permettaient de bien les distinguer.

Vincent [00:34:30] Donc l’idée, c’est de se dire que c’est finalement beaucoup d’empathie et que les gens qui vont utiliser les choses qu’on fait n’ont pas tous les mêmes yeux que nous, les mêmes oreilles…

Loïc [00:34:42] Ils n’ont pas le même bagage culturel, ils n’ont pas les mêmes langues maternelles…

Vincent [00:34:45] Les mêmes cultures, etc.

Loïc [00:34:56] J’aimerais rebondir sur un truc que tu (ndlr: Loïc s’adresse à Matthieu) as dit il y a un moment : tu parlais du fait que si on a une application qui n’est pas accessible, de facto on n’aura pas d’utilisateurs qui vont l’utiliser, qui ont besoin de cette accessibilité. Je pense qu’aujourd’hui, cet argumentaire-là est d’autant plus important parce que beaucoup d’entreprises ont tendance à faire ce que l’on appelle du “data-driven”, donc de prendre des décisions basées sur de la donnée. Et la donnée, c’est quoi ? Généralement, c’est de la donnée de retours utilisateurs, souvent sous forme de tracking. Parce que c’est quand même ça aujourd’hui qu’on fait le plus dans notre industrie : savoir comment nos utilisateurs utilisent l’application et traquer presque leurs moindres faits et gestes dans l’optique de comprendre comment ils utilisent l’application, qu’est-ce qu’on doit améliorer, où est-ce qu’il y a des problèmes… Et comme tu dis, ne pas avoir d’utilisateur qui utiliserait ces fonctionnalités d’accessibilité nous prive de tous ces chiffres et nous empêche d’avoir le genre de statistiques que Céline a sorties tout à l’heure. Par exemple, quand tu disais que tu avais 20% d’utilisateurs qui utilisaient les gros caractères, ça, ce n’est possible que si les gros caractères sont disponibles et accessibles. Je pense qu’aujourd’hui — depuis un ou deux ans et dans les années qui vont venir — c’est d’autant plus crucial parce que la philosophie du data-driven est de plus en plus présente, de plus en plus importante. Et du coup, l’objectif, c’est presque de faire rentrer de la donnée pour faire prendre conscience de manière la plus objective possible que oui, ça concerne tant de pourcents de gens et que ce n’est pas juste une affabulation de gens qui sont un peu trop empathiques.

Céline [00:36:30] Et on parlait tout à l’heure de formation aussi, du fait que ça vient en grande partie d’un manque d’information des équipes. Au même titre que quand on arrive dans une société, on doit suivre un certain nombre de formations sur la sécurité, sur l’inclusion, sur ce genre de choses… On pourrait très bien avoir un module de formation sur l’accessibilité avec un professionnel qui se déplace. Il y a des certifications officielles qui existent en plus et qui pourraient être, par exemple, obligatoires pour certains métiers. Donc, à l’échelle de l’entreprise, c’est possible aussi d’avoir des leviers d’action. Ce n’est pas simplement qu’au niveau de l’éducation — qui risque de prendre plus de temps !

Loïc [00:37:04] Oui, j’avoue, ce serait bien d’avoir des formations dans le parcours d’onboarding. Des formations potentiellement internes avec des gens qui sont sensibilisés, mais aussi des formations — tu parlais de certification — donc qui vont potentiellement sanctionner les connaissances et le fait d’avoir au moins suivi les formations en question.

Céline [00:37:24] Tout à fait.

Matthieu [00:37:25] Oui, je pense qu’il y a un véritable besoin de sensibilisation. On est des bons exemples autour de la table. Ce qui s’est passé avec nous, c’est qu’on s’est retrouvé sur un projet, on avait besoin de faire de l’accessibilité, on a vu ce que c’était que l’accessibilité et on s’est rendu compte de son importance. Et je pense qu’il y a un manque de sensibilisation auprès des développeurs. Une fois qu’on teste une application et qu’on essaye de comprendre, d’utiliser le lecteur d’écran comme une personne qui a une déficience visuelle, on se rend compte de la difficulté. Je pense qu’on développe aussi de l’empathie envers ces personnes et on comprend le parcours que peuvent avoir ces personnes dans une application. Et c’est à partir de ce moment-là qu’on se dit : “il faut faire quelque chose”. En tout cas, pour moi, c’est vraiment ce qui s’est passé et c’est pour ça que je continue, à travers toutes les entreprises que j’ai pu fréquenter, de continuer à pousser l’accessibilité. Parce que je me suis rendu compte que c’était un besoin important grâce à un moment donné. Je pense que s’il y avait un peu plus de sensibilisation auprès des développeurs qui n’ont pas eu accès au domaine de l’accessibilité dans leur cursus professionnel ou scolaire, ça débloquerait beaucoup de choses et donnerait lieu à une plus grande connaissance et plus d’investissement dans l’accessibilité.

Vincent [00:38:36] Pour vous, s’il y avait une chose à faire là : la personne arrête d’écouter notre podcast maintenant, dans les cinq minutes qui viennent, qu’est-ce qu’elle doit faire pour se sensibiliser tout de suite à l’accessibilité ? Le truc le plus efficace pour l’onboarder ? En tout cas si c’est quelqu’un qui veut essayer de se lancer.

Dorothée [00:38:54] Sur iOS, il y a une fonctionnalité que l’on peut activer, qui s’appelle “Screen Curtain”. Quand on l’active, l’écran devient tout noir. Donc j’invite les auditeurs à activer ce réglage-là et à essayer d’utiliser Deezer ou n’importe quelle autre application. Et là, on se rend vraiment compte de ce qui se passe.

Matthieu [00:39:14] Je continue sur l’idée du lecteur d’écran. Je pense que le lecteur d’écran c’est là où l’on se rend compte que c’est compliqué. Bien souvent, on l’active par erreur et on a beaucoup de mal à le désactiver. Activez-le, continuez à l’utiliser, ayez du mal à le désactiver parce que ça fait partie de l’expérience — parce que vous allez utiliser le lecteur d’écran pour désactiver le lecteur d’écran — mais continuez à l’utiliser et regardez un peu comment aller sur Chrome, aller sur un site internet — ça peut être sur votre smartphone, ordinateur ou tablette. Maintenant, toutes les plateformes ont un lecteur d’écran embarqué et je pense que c’est un très bon choc !

Vincent [00:39:57] Céline ?

Céline [00:39:58] Moi, j’inviterais les utilisateurs — tout le monde a un smartphone sur soi, allez dans le menu “Accessibilité” qui est disponible dans les réglages et amusez-vous avec. Familiarisez-vous avec parce que ça vous mettra un petit peu dans la peau d’un utilisateur. Utilisez, par exemple, le grossissement de texte : regardez vos applications favorites et regardez si elles permettent le grossissement de texte, vous aurez certainement des surprises !

Loïc [00:40:21] Je rajouterais, pour le côté web, n’hésitez pas à utiliser les outils des navigateurs. Ils sont de plus en plus performants par rapport à l’accessibilité. Je sais qu’au moins dans Firefox, pour tous les intégrateurs HTML CSS, vous pouvez ouvrir l’inspecteur pour voir le code et vous pouvez avoir des analyses d’accessibilité en temps réel sur le site web que vous êtes en train de visiter. Ça va vous donner des informations objectives comme, par exemple, le taux de contraste des textes, à savoir : est-ce que le texte que vous avez mis en noir sur du gris anthracite est accessible ou pas ? Il y a énormément de standards qui existent pour faire ces calculs et le navigateur va vous donner une note. Je crois que ça va de “pas accessible” — globalement, quand on commence à avoir des notes comme B, C, …, en gros, c’est que vous allez avoir du mal à lire, mais quand on est dans du A, du double A, voire du triple A, c’est qu’on favorise l’accessibilité du texte par exemple. Donc en gros, la gestion du contraste : par exemple, avec un noir sur blanc — un vrai noir, un vrai blanc, dans le sens 00 et FFF pour le blanc — vous allez avoir un taux de contraste parfait. Sauf qu’on est rarement sur ces couleurs-là dans nos designs. Mais justement, le navigateur intègre les outils pour vous montrer en temps réel : vous allez pouvoir modifier les couleurs jusqu’au moment où vous basculez dans quelque chose qui est moins accessible. Et pour des fonctionnalités essentielles par exemple, visez des niveaux d’accessibilité hauts, et pour des fonctionnalités peut-être plus secondaires, visez des niveaux d’accessibilité normaux ou un peu plus faibles, mais tout en restant dans quelque chose d’accessible pour éviter les écueils du texte noir sur fond noir ou jaune sur fond vert. C’est très facile à utiliser et c’est très objectif, c’est-à-dire qu’il n’y a plus votre interprétation, il n’y a plus votre écran qui, potentiellement, change la donne — puisque l’écran de chacun, au niveau des couleurs, va modifier la façon dont les graphismes sont représentés. Là, vous avez quelque chose qui est purement mathématique, qui peut servir de base.

Matthieu [00:42:14] De façon visuelle aussi, avec l’inspecteur dans Chrome il me semble et peut-être dans Firefox aussi — alors c’est peut-être quelque chose qui va s’orienter plus pour les développeurs ou pour les designers — on a la possibilité de simuler l’application avec un film qui va nous permettre d’avoir un certain type de daltonisme, donc de voir l’application avec les yeux d’une personne qui a une déficience, par exemple, dans les couleurs rouges, dans les couleurs bleues ou dans les couleurs vertes, et de se rendre compte de l’utilisation des couleurs. Parce que je pense qu’il y a le contraste qui est très important, mais il y a aussi un risque d’utiliser des couleurs qui sont mitoyennes dans l’interface, et pour lesquelles on ne va pas voir de différence entre différents cas de daltonisme. Donc ça, c’est un outil qui est utilisable aussi dans Chrome et je pense dans beaucoup d’applications de design comme Figma ou InVision.

Vincent [00:43:04] Merci beaucoup, je crois qu’on va conclure là-dessus. C’était vraiment super enrichissant encore une fois, merci à tous les trois. Je vous propose de passer tout de suite à la dernière séquence…

Loïc [00:43:15] Les coups de cœur ! On est à Deezer donc la question, c’est : qu’est-ce que vous nous recommanderiez d’écouter suite à notre discussion ?

Matthieu [00:43:30] Alors, suite à la discussion, je ne sais pas !

Loïc [00:43:36] Ça peut être totalement lié ou pas, c’est à vous de décider !

Matthieu [00:43:39] Alors moi, en ce moment, mon petit coup de cœur, c’est une artiste qui s’appelle Susanne Sundfør. Je ne sais pas de quelle origine elle est, il me semble peut-être norvégienne ou danoise. Mais voilà, c’est mon petit coup de cœur en ce moment et je suis bloqué sur ses albums.

Vincent [00:43:55] Super.

Loïc [00:43:55] Dorothée ?

Dorothée [00:43:56] De mon côté, il y a une chanson que j’écoute en boucle, c’est “From Can to Can’t” de l’album “Sound City” avec Dave Grohl. Donc je vous recommande ça, mais comme moi, vous allez peut-être bloquer dessus ! Sinon, je voulais aussi vous partager une chanson qui s’appelle “Calentita” de The Liminanas, c’est super marrant. Parce que je voulais finir sur une note un peu drôle. Enfin, moi, elle me fait trop rire cette chanson.

Vincent [00:44:18] De manière générale, les Liminanas, c’est toujours un petit peu barré ! C’est toujours sympathique !

Dorothée [00:44:23] Voilà, je vous invite à écouter et à regarder le clip si vous êtes fous !

Vincent [00:44:27] Et Céline ?

Céline [00:44:28] Et de mon côté, je vous conseillerais l’écoute de Jon Batiste. C’est un jazz man, il a notamment fait la bande-son du dernier Disney, “Soul” — qui est peut-être plutôt un Pixar d’ailleurs — et qui est excellent. Si vous aimez le jazz, Jon Batiste, c’est fait pour vous !

Vincent [00:44:45] Je confirme, je ne suis pas très jazz et pourtant la bande-son de ce film est géniale.

Loïc [00:44:51] Je plussoie.

Vincent [00:44:53] Eh bien merci à tous les trois encore. Maintenant, les auditeurs ont bien compris : la première chose qu’ils font en sortant d’ici, c’est d’aller regarder des sites et des applications directement en se mettant dans la peau des gens en situation de handicap. Et puis, je propose de se revoir la prochaine fois !

Loïc [00:45:06] À la prochaine fois !

Dorothée [00:45:07] Merci !

Matthieu [00:45:08] Merci !

Céline [00:45:08] Merci !

Références