Verbatim de la présentation VoxxedDays Luxembourg 2026
Slide 1
Nous sommes Alain Vagner et Dominique Nauroy, nous vous présentons cet après-midi ce qui a été pour nous une petite aventure technique : la mise au point d’une voix luxembourgeoise adaptée aux technologies d’assistance utilisées par les personnes en situation de handicap. Voilà pourquoi nous avons intitulé notre présentation « Lire à la volée le luxembourgeois : une innovation et un progrès pour l’accessibilité ». Petite question : y a-t-il des luxembourgophones dans la salle ?
Slide 2
Vous pouvez retrouver cette présentation ainsi qu’une transcription textuelle à l’aide de ce QR Code.
Slide 3
Nous nous présentons en deux mots.
Slide 4
Qui sommes-nous ?
Nous travaillons depuis 2020 au sein du Service information et presse du gouvernement sur l’accessibilité numérique. Vous pouvez nous retrouver sur les réseaux sociaux derrière le nom « Accessibility Luxembourg ».
Nous pouvons résumer ainsi nos missions :
- Le contrôle de la conformité des sites et des apps mobiles des organismes du secteur public
- La sensibilisation: nous donnons des formations sur le sujet, et nous publions des articles de vulgarisation sur notre site accessibilite.public.lu.
- Nous offrons une médiation entre les utilisateurs qui rencontrent des problèmes d’accessibilité et les administrations
Donc, nous avons des profils qui mêlent développement, expertise en accessibilité à un peu de pédagogie et de sens de la communication. En revanche nous ne sommes pas des linguistes, on a un peu appris sur le tas.
Slide 5
Nous vous présentons en deux ce qu’est l’accessibilité numérique, puisque c’est dans ce contexte qu’a démarré le projet.
Slide 6
L’accessibilité numérique a pour but de garantir à tous, sans discrimination, un même accès à l’information et aux services en ligne, quelle que soit la nature du handicap des personnes et la façon dont chacun consulte l’information.
Slide 7
Les handicaps sont multiples : on peut par exemple être aveugle, sourd, ou être né avec un handicap physique ou cognitif.
Il existe de nombreuses variantes ou combinaisons de ces handicaps.
On peut par exemple être malvoyant ou daltonien
On peut être aveugle et sourd en même temps.
15% des personnes handicapées sont venues au monde avec un handicap, tandis que 85% le sont devenues suite à une maladie ou un accident.
Pour l’OMS, « le handicap n’est pas simplement un problème de santé. Il s’agit d’un phénomène complexe qui découle de l’interaction entre les caractéristiques corporelles d’une personne et les caractéristiques de la société où elle vit. Pour surmonter les difficultés auxquelles les personnes handicapées sont confrontées, des interventions destinées à lever les obstacles environnementaux et sociaux sont nécessaires. »
Il ne s’agit donc pas seulement d’une question médicale, c’est aussi une question de société : la société doit être adaptée aux personnes handicapées.
Slide 8
Sur ordinateur ou téléphone, des lecteurs d’écran restituent le contenu affiché l’écran et le vocalisent.
Les lecteurs d’écran permettent aussi une restitution via une plage braille pour les utilisateurs qui lisent le braille. Quelques exemples de lecteurs d’écran : VoiceOver sur macOS ou iOS, TalkBack sur Android ; NVDA, Narrator, JAWS sur Windows.
Slide 9
La restitution vocale est immédiate, il n’y a aucun temps de latence. La réactivité est cruciale et prime sur la qualité audio, ex : quand on est sur un écran, et que l’on clique quelque part, on ne veut pas attendre. On remarque une latence à partir de 250ms. Alors imaginez si votre seul canal de retour c’est la voix et que vous devez attendre 2s à chaque action...
La restitution vocale décrit le contenu et la structure d’une page, par exemple les titres et les listes à points.
Elle décrit la fonction de chaque élément interactif, ex: bouton, lien, champ de formulaire…
Elle fonctionne à très haute vitesse.
Elle s’adapte à toutes les langues présentes dans un même document, il est possible d’avoir plusieurs langues, surtout au Luxembourg, et la bonne voix sera utilisée pour chaque langue si on a les bonnes informations dans le code.
Elle fonctionne sans connexion à un service distant, critère critique pour la vie privée.
Slide 10
Acte 1 : le problème
Slide 11
En l’absence d’un véritable TTS luxembourgeois, la meilleure solution jusqu’ici consistait à utiliser une synthèse allemande pour lire du luxembourgeois : ce n’était pas optimal.
Pourquoi ? C’est frustrant, c’est une perte de temps et cela peut avoir un véritable impact quotidien : si on travaille 8h par jour avec cela, cela peut être la cause d’une charge cognitive supplémentaire, donc d’une fatigue accrue. C’est quand même plus agréable d’avoir une synthèse dans sa langue.
Slide 12
À quoi ressemblait la situation jusqu’en 2026 ? Nous avons fait lire le même article par trois synthèses vocales, à vous de nous dire laquelle vous semble la plus compréhensible.
Slide 13
Le premier extrait est lu par la synthèse luxembourgeoise eSpeak. C’était jusqu’ici la seule compatible avec les lecteurs d’écran, mais la qualité de la restitution n’était pas au niveau.
Le deuxième extrait est lu avec un TTS allemand sous macOS.
Le dernier est lu grâce à la synthèse développée par le Zenter fir d’lëtzebuerger Sprooch, centre pour la langue luxembourgeoise (ZLS). La qualité est nettement meilleure, c’est le moteur utilisé notamment pour sproochmaschinn.lu. Seul bémol dans notre cas : elle n’est pas adaptée aux lecteurs d’écran et ne répond pas à plusieurs critères essentiels, dont la réactivité (l’absence de latence) ou la lecture à très haute vitesse.
Slide 14
Interopérabilité avec les différents lecteurs d’écrans
Il n’y a pas de standard qui couvre tous les OS et screen readers pour les synthèses vocales. Sous Windows il y a le standard SAPI5 qui est largement supporté. Mais il convient de développer des intégrations spécifiques pour chaque lecteur d’écran / OS.
Le luxembourgeois, un low-resource language
Cela signifie que la langue compte peu de locuteurs, comparé à d’autres langues. Elle suscite, de même, peu d’intérêt des grands éditeurs américains.
Le multilinguisme
On est dans un contexte multilingue, on ne peut pas travailler en silo et produire une voix purement luxembourgeoise. Cette voix doit être capable de prononcer des mots de français et d’allemand sans souci.
L’open source
Les grands acteurs du domaine (Microsoft, Nuance, ...) produisent des voix mais leur code est majoritaitement propriétaire. Il y a quelques moteurs de voix comme espeak-ng en open source, mais avec une qualité limitée et une sortie très peu naturelle. L’open source est un critère majeur, dans la mesure où l’argent public doit aussi déboucher sur du code public.
Slide 15
Acte 2 : Wëllkomm Mia a Mil!
Nous avons passé un moment à vous évoquer le contexte mais aussi les attendus du projet, à présent nous vous présentons la solution, qui a abouti à la publication de deux voix, Mia et Mil.
Slide 16
On vous propose ici une petite démonstration des voix en utilisation sur une page web. Ces voix répondent au cahier des charges tel qu’il a été défini, elles sont notamment interopérables et disponibles sous cinq environnements (macOS, Windows, Linux pour le monde desktop, iOS et Android pour les terminaux mobiles).
Slide 17
Nous n’avons pas travaillé seuls. C’est véritablement une association de compétences qui a permis au projet de voir le jour, entre le SIP, le ZLS, le CDV (le centre pour le développement des compétences relatives à la vue) et le ministère de la Digitalisation (sans parler, encore à ce stade, du prestataire).
- Le ZLS est la référence pour tout ce qui touche à la langue Luxembourgeoise, ils gèrent LOD, le Spellchecker, et aussi la Sproochmaschinn. Ce sont des champions de l’open data : leurs données sont parmi les plus réutilisées. Ils ont des données qui nous intéressent : la phonétique de chaque mot dans le dictionnaire et aussi des enregistrements de chaque mot.
- Le CDV : on ne fait pas un produit pour les aveugles sans les impliquer. Le CDV est la référence au Luxembourg, expliquer leurs missions, ils font aussi régulièrement des projets d’innovation.
En résumé, le ZLS fournit les données et l’expertise linguistique, le CDV fournit l’expertise accessibilité et usages, ainsi que le testing.
Slide 18
À l’issue d’un appel d’offres, nous avons retenu la solution RHVoice.
Pourquoi n’a-t-elle pas de réel challenger ?
D’abord elle offre une bonne compatibilité avec les screenreaders et les OS existants.
Elle fonctionne sur des low-power devices, sans besoin d’un processeur spécifique IA ou d’un gros GPU avec plein de RAM.
C’est une solution open source !
Sa conceptrice, Olga Yakovleva, dispose d’une expérience reconnue dans le support des « low resource languages ».
Support existant pour les langues suivantes : albanais, croate, tchèque, anglais, espéranto, géorgien, kirghize, macédonien, népalais, polonais, portugais (Brésil), roumain, russe, serbe, setswana, slovaque, espagnol, tatar, turkmène, ukrainien, ouzbek, vietnamien du Sud
Parmi ces langues, certaines sont « low resources » : Albanian, Georgian, Kyrgyz, Macedonian, Setswana, Tatar, Turkmen, Uzbek.
Mais même pour ces langues, le nombre de locuteurs est plus élevé que pour le luxembourgeois (se compte en millions, sauf peut-être pour l’Espéranto).
Dans tous les cas, le but de ce projet est de permettre aux aveugles qui parlent ces langues d’avoir accès à une synthèse vocale de qualité, alors que leur langue n’est pas supportée par les principaux OS du marché.
Slide 19
La solution basée sur RHVoice a été testée…
- Par des personnes voyantes
- Tests en situation : génération de sons pour des articles sur les principaux sites en luxembourgeois (RTL, 100,7), écoute de ces enregistrements et remontée des mots mal prononcés
- Tests synthétiques : génération d’échantillons de mots sur base des dictionnaires FR et LB intégrés à la voix, détection de patterns de problèmes
- Par des personnes aveugles
- Tests en situation réelle, beta test
- Organisation d’install party: la principale barrière à l’adoption, amener les gens à installer et configurer les voix, ce qui n’est pas toujours évident
Slide 20
Acte 3 : on ouvre le capot.
C’est maintenant le cœur de cette présentation, on vous montre comment nous avons fait dialoguer technique et linguistique.
Slide 21
On fait un petit pas de côté pour rappeler les principales familles de synthèse vocales.
- Concaténative: fonctionne par assemblage d’extraits audio de voix enregistrées. Produit des voix assez naturelles car basées sur de vrais enregistrements mais peu flexibles, difficile d’ajuster le ton ou la vitesse. Transitions peu fluides. Ex: vieux serveurs téléphoniques vocaux. Cette techno est ancienne. Exemple de moteurs open source : Mbrola, Festival
- Paramétrique: génère de la parole à partir de modèles mathématiques (formants ou statistiques). Plus flexibles que les concaténatives, on peut régler le débit et l’intonation. L’inconvénient est que les voix sont un peu robotiques. Ces voix sont les plus frugales, en termes de puissance de calcul, de mémoire et de stockage. Exemples de moteurs open source: eSpeak ou RHVoice. La différence entre les deux, eSpeak se base sur les formants, et RHVoice sur un modèle statistique, le modèle de Markov caché), RHVoice sonne un peu moins robotique qu’eSpeak.
- Neuronale: les voix neuronales sont les plus naturelles. Le problème est qu’elles demandent beaucoup plus de puissance de calcul pour fonctionner, pour certains la présence d’un GPU. La réactivité n’est pas optimale.
- Les derniers développements de l’IA ne nous aident pas forcément : au vu de nos contraintes, seule la famille paramétrique colle à nos besoins, c’est la plus frugale, elle est flexible et permet de régler la vitesse et l’intonation.
- Choix technique : pourquoi pas le deep learning ? On voulait quelque chose de vraiment peu gourmand, qui fonctionne sur un Android avec peu de RAM d’il y a 10 ans, et qui est super réactif. On arrive à avoir cela avec cette techno de génération N-1. Au niveau puissance CPU, il faut aussi s’imaginer que votre téléphone ou votre ordinateur exécute d’autres tâches en même temps et que la lecture de la voix ne doit pas saccader. Cela correspond mieux à nos besoins spécifiques. Si on s’appelait Microsoft ou Google, on pourrait certainement se payer une solution de type deep learning réactive, mais notre budget était bien plus limité.
Slide 22
Pour comprendre comment ça marche, on va étudier le processus qui convertit du texte en parole.
On démarre par la source. On affiche un texte en luxembourgeois dans une page web.
Le navigateur a une representation en mémoire que vous connaissez bien, le DOM html.
Ce DOM est synchronisé avec une autre representation en mémoire qui s’appelle l’accessibility tree. Cet arbre est indépendent de la technologie et fonctionne aussi pour les applications, pas uniquement pour du HTML.
C’est l’information qui va être lue par le lecteur d’écran, celui-ci ne lit pas le HTML.
Slide 23
L’accessibility tree est lu par le lecteur d’écran. Celui-ci va convertir l’information dans un format compréhensible par la voix, ici au format SSML. L’interaction entre le lecteur d’écran et le TTS se fait via une API standardisée, comme SAPI5 sous Windows.
Le TTS n’a aucun contrôle sur la manière dont le texte est découpé (phrase ou partie, caractères à épeler…)
Le moteur de RHVoice convertit le texte en phonèmes via son G2P, et ensuite les phonèmes sont envoyés au modèle statistique, qui convertit les phonèmes en sons.
Ce qu’on voit en bas de l’écran correspond à la syntaxe RHVoice avec les phonèmes des voix luxembourgeoises.
Slide 24
Sur base d’enregistrements fournis par le ZLS, apprentissage du mapping phonème -> son.
C’est la partie un peu boite noire, on a donné des enregistrements avec les mots et la phonétique au prestataire, il a entrainé un modèle et produit des fichiers binaires.
S’il y a des problèmes sur certains phonèmes, en théorie on pourrait réentraîner le modèle mais pour cela il faudrait un certain nombre de nouveaux enregistrements bien ciblés autour du problème.
Les modèles sont paramétriques, on peut effectuer certains réglages.
Les voix ont notamment été déguisées pour qu’elles ne soient pas reconnaissables.
On envoie des phonèmes au modèle et on reçoit du son.
Le processus est basé sur la techno HTS, Hidden-Markov models Text-to-speech
Slide 25
Toute synthèse vocale va avoir besoin d’une conversion des graphèmes (ce qui est écrit) en phonèmes (ce qui est oralisé).
Slide 26
Les règles linguistiques exprimées en FOMA
foma est un langage et son compilateur pour automates finis, couramment utilisé dans le TALN (traitement automatique du langage naturel, NLP natural language processing en anglais)
Automate finis, un rappel pour ceux qui ont zappé le cours à la FAC :
Exemple d’automate à état fini pour un portillon (source Wikipedia https://en.wikipedia.org/wiki/Finite-state_machine)
On en retrouve partout. « L’IA » dans Doom, c’était un automate à états finis.
Avec FOMA, on peut décrire et exécuter des automates finis, mais aussi des « transducteurs », ce sont des cas particuliers d’automates finis qui produisent une sortie à partir de l’entrée. Le G2P est globalement un gros transducteur qui traduit une entrée « un graphème » à une sortie « un phonème ».
Tout le code de notre G2P en foma est open source :
https://github.com/accessibility-luxembourg/RHVoice-Luxembourgish-src
Slide 27
On va pouvoir décrire par du code, l’ensemble des règles de prononciation. Si quelque chose est mal prononcé, on peut revoir la règle.
Qu’est-ce qu’on peut gérer comme règles ?
- la tokenisation (découpage de la phrase en mots),
- la prononciation de l’alphabet, des nombres (grands nombres, codes postaux, numéros de tel, chiffres romains),
- la gestion de mots dans le dictionnaire (prononciation phonétique),
- la gestion de mots non trouvés dans le dictionnaire,
- les mots composés,
- les symboles et emojis, abréviations, émojis,
- les intonation (ex : questions)
Slide 28
On a écrit quelques règles pour transformer quelques mots de français en leur équivalent phonétique. C’est juste pour l’exemple, pour le français ou le luxembourgeois on a des centaines de règles de la sorte. On utilise ici l’alphabet IPA (alphabet phonétique international).
La première règle convertit la séquence de lettres ch en le phonème ʃ
La deuxième règle gère la lettre c. Celle-ci est traduite en son “k” si elle est suivie des lettres a o u ou r. Le double “pipe” indique une condition.
Ensuite la lettre i est convertie en son « j » si précédée des lettres ch (le i court dans chien)
Les lettres e ou t en fin de mot sont muettes.
On peut composer des règles ensemble via l’opérateur .o.
Si des lettres ne matchent pas, elles passent directement dans la sortie
On voit que ça ressemble à des regex
Slide 29
On a un processus par étape pour trouver la prononciation d’un mot. Si on trouve le mot à une étape, alors on arrête et on récupère sa prononciation.
- Un dictionnaire utilisateur, n’importe quel utilisateur peut customiser la prononciation de certains mots en créant ce type de dictionnaire en local.
- Le dictionnaire luxembourgeois, qui contient une extrapolation phonétique des mots dans LOD
- Le dictionnaire de français, qui vient d’un projet open source de dictionnaire IPA
- La gestion des mots composés, on essaie de couper le mot composé en sous-parties et de trouver leur prononciation dans le dictionnaire luxembourgeois
- Si on n’a rien trouvé jusqu’ici, alors on a un ensemble de règles de prononciation génériques qui s’appliquent. C’est le dernier recours
Slide 30
Cette façon de gérer pour le luxembourgeois est la plus complexe de RHVoice. Pour l’espagnol par exemple, il n’y a que 2 étapes : 1/ dictionnaire, 2/ règles de prononciation. C’est possible de fonctionner comme ceci pour l’espagnol car c’est une langue très transparente, elle se prononce globalement comme elle s’écrit. Le dictionnaire est uniquement utilisé pour les noms étrangers et pour les mots d’emprunt.
Cette approche a quelques limites, il y a des mots qui apparaissent à la fois dans le dictionnaire français et dans le dictionnaire luxembourgeois, avec des prononciations différentes. Dans ce cas, c’est la prononciation luxembourgeoise qui prime, même si le mot est dans une phrase en français.
Il y a 500 mots de ce type, mais les problèmes de prononciation sont minimes. Comme le luxembourgeois a une priorité sur le français, c'est surtout en français que les problèmes pourraient apparaitre, ce qui est moins grave pour une voix luxembourgeoise.
Slide 31
Processus pour l’ajout de mots au dictionnaire
- Écouter des textes et relever les mots mal prononcés
- Saisie phonétique avec l’outil interne
- Vérification que la transcription X-SAMPA « compile » (les phonèmes saisis sont reconnus)
- Cycles d'écriture phonétique, test et écoute
- Discussions pour les transcriptions de mots étrangers, par ex: prononciation des r en anglais avec un accent étranger
Slide 32
On peut transcrire la phonétique en API ou en X-Sampa, les deux sont équivalents. On a trouvé sur internet un dictionnaire français en API, qu’on a pu convertir en X-SAMPA. Pour nous, on a travaillé directement en X-Sampa, car nous avons jugé plus pénible de taper les caractères spéciaux API.
Slide 33
Quelques exemples de mots transcrits en alphabet phonétique international et en X-SAMPA.
Slide 34
On a dû développer des scripts pour calculer la phonétique de déclinaisons de mots. On a dans LOD la phonétique seulement pour les noms au singulier, idem pour les verbes, ils ne sont pas conjugués. Pour les mots de français, on est partis sur un dictionnaire open source.
En faisant des tests, on a découvert des mots mal prononcés, on les a donc transcrit en X-SAMPA et ajoutés au dictionnaire. C’est un exercice qui devrait être poursuivi, car une langue est vivante, il y a constamment des nouveaux mots.
Développement d’un vocabulaire spécifique :
- Acronymes (ex: CGDIS, CTIE, …)
- Prénoms, noms de famille
- Noms de sociétés
- Célébrités, …
Pour les célébrités, les noms de sociétés, les prénoms et noms de famille, on a pris à chaque fois le top 100 des plus courants, on les a testés, puis on a transcrit tous ceux qui posaient problème. À noter que pour certains mots de langues étrangères, on n’avait pas forcément les phonèmes à dispo. Si dans les enregistrements il n’y avait pas assez de mots avec ce phonème, il n’y avait pas de possibilité d’entrainer correctement ce son et donc on essayait de trouver un phonème proche. (c’est ce que font tous les Français quand ils parlent anglais avec un fort accent français ;))
- Acronymes, noms propres, prénoms
- Partir de listes publiquement disponibles / open data
- Ex : top 100 des entreprises luxembourgeoises du STATEC, liste des administrations et établissements publics, listes de prénoms luxembourgeois, noms des députés et ministres, prénoms en français, allemand, portugais, célébrités, ...
Exemples issus de notre dictionnaire où on a ajouté ou corrigé environ 500 mots :
Pour développer le dictionnaire, on s’est développé un petit clavier phonétique. C’est un outil interne très basique pour l’instant.
Slide 35
Slide 36
Acte 4 : challenges et leçons
Qu’est-ce qui a fonctionné ?
Qu’est-ce qui nous est apparu difficilement surmontable ?
Qu’avons-nous pu sous-estimer ?
Slide 37
On a beaucoup de mots d’anglais dans les interfaces pas complètement traduites. Ça peut être au niveau du système d’exploitation ou des sites (par ex des alternatives d’images, des étiquettes de boutons, pas visibles pour nous, mais restituées aux lecteurs d’écrans).
Il était trop complexe d’intégrer un dictionnaire d’anglais en plus du luxembourgeois et du français dans l’architecture actuelle (en plus des overlaps de mots entre langues), en conséquence on a choisi une autre stratégie, mettre en place un switch auto entre la langue luxembourgeoise et la langue anglaise.
Détection automatique de langue dans une phrase : si plus de 50% des mots sont anglais, on switche en anglais. Le mode est désactivable. Rien de tel qu’une voix anglaise pour prononcer de l’anglais. Les phonèmes à disposition pour prononcer de l’anglais étaient bien trop limités. Sur un site web on a encore un 2e niveau de switch auto, basé sur les attributs lang, mais ne fonctionne qu’entre les langues supportées par la synthèse vocale.
Slide 38
On a demandé à des traductrices professionnelles de revoir les traductions des symboles.
Le problème est qu’à part sur Android, les symboles sont traités en amont de la synthèse vocale. Nous avons donc créé des packs de traductions pour les lecteurs d’écrans sous Windows NVDA et Jaws. NVDA étant open source, les traductions ont été intégrées dans le projet et on n’a plus besoin de ce pack. Pour Jaws, c’est un produit commercial, nous avons proposé à la société américaine qui gère le logiciel d’intégrer ces traductions, pour l’instant rien de concret.
Pour les emojis, il y a une liste officielle d’emojis définis par le CLDR avec des traductions dans toutes les langues dont le luxembourgeois.
Certaines traductions nous semblent un peu alambiquées, mais il est difficile de maintenir une liste de modifications à notre niveau, car le CLDR pousse au moins une fois par an une liste mise à jour, il faudrait donc maintenir un patch relativement complexe. S’il y a des problèmes sur certaines traductions, le mieux est donc de faire des propositions au CLDR. Ce que nous n’avons pas fait, mais ce qu’un organisme comme le ZLS pourrait faire si besoin.
Slide 39
Il y a des bugs ou d’autres éléments sur lesquels nous n’avons pas le contrôle.
Il en est ainsi des symboles ou des émojis sous iOS.
Toujours sous cette plateforme, le point est systématiquement lu « dot », même dans le contexte d’une phrase en luxembourgeois.
Problème de la langue de certains boutons car le luxembourgeois n’est pas reconnu.
Problème des majuscules minuscules (le texte est parfois envoyé en minuscules au TTS, alors que la majuscule en début de mot est importante en luxembourgeois).
On a des contacts chez Apple, ces problèmes sont en voie de résolution.
Slide 40
Normalement on peut en html spécifier la langue d’un élément avec l’attribut « lang ». Les lecteurs d’écrans peuvent switcher automatiquement de voix pour lire le texte avec la bonne langue.
Malheureusement ce mécanisme fonctionne mal avec plusieurs lecteurs d’écrans et nos voix luxembourgeoises :
- Sur iOS, la langue luxembourgeoise n’est pas reconnue officiellement par l’OS. Il n’y a donc pas de switch automatique possible vers nos voix.
- Sur Windows, les lecteurs d’écrans acceptent de switcher vers d’autres voix d’un même moteur. Dans notre cas, RHVoice n’a pas encore de voix française ou allemande, le switch ne fonctionne qu’avec l’anglais.
Slide 41
Quand on a développé ces voix, on a surtout pensé à un usage « passif », la lecture d’articles sur des sites en luxembourgeois. Or le principal usage est surtout actif, dans la discussion par email ou WhatsApp. Cela a un impact sur la qualité de la voix, car la qualité de l’orthographe n’est pas la même et même si nos voix sont relativement robustes, les problèmes d’orthographe ont un impact sur la prononciation.
La qualité de l’orthographe augmente, notamment par toutes les actions du ZLS, et les formations qui existent, mais c’est encore un souci pour nous.
Slide 42
Il ne suffit pas de publier une technologie pour qu’on se l’approprie immédiatement.
Il faut communiquer, gérer le changement, aider les gens à installer, assurer un support.
Tout cela prend du temps, plus que ce que nous avions prévu.
Les gens peuvent aussi être plus motivés s’ils reçoivent une contrepartie. Nous n’avions pas prévu cela.
Slide 43
Suite à un sondage publié au moment d’une beta publique, les retours que nous avons recueillis étaient clairement positifs et encourageants.
Slide 44
Idem sur les réseaux sociaux, des retours positifs
Slide 45
Nous vous proposons d’essayer par vous-mêmes, sans rien installer, grâce à un portage réalisé par nos soins en ligne.
Slide 46
En conclusion…
Slide 47
C’est un projet ambitieux, qui a débouché sur des résultats concrets :
Deux voix
- offline,
- cross platform,
- open source,
- réactives,
- à l’aise même à haute vitesse
Vous êtes invités à vous les approprier !
Tout est dispo sur notre site, si vous voulez essayer, les instructions d’installation et de configuration sont dispo.
Toute contribution est bienvenue !
Slide 48
Voilà, cette présentation touche à sa fin. Nous vous remercions pour votre attention. Vous trouverez sur cet écran notre adresse e-mail si vous souhaitez nous contacter : accessibilite@sip.etat.lu, ainsi que l’URL de notre portail : accessibilite.public.lu. Vous pouvez enfin suivre notre actu, nous sommes présents sur Bluesky, LinkedIn et Mastodon, et vous pouvez aussi vous inscrire à notre newsletter.
Crédits photo
Slide 4 : CC Attribution-SharaAlike https://en.wikipedia.org/wiki/File:G%C3%ABlle_Fra_World_War_I_Memorial_Luxembourg_City_13_04_2008.jpg
Slide 6 : CC DNB, Stephan Jockel
Slide 8 : Getty Images / istockphoto.com / SilviaJansen
Slide 10 : génération d'image depuis Copilot
Slide 15 : CC Shalev Cohen licence Unsplash https://unsplash.com/fr/photos/deux-jeunes-enfants-assis-sur-des-chaises-les-mains-en-lair-67XFQhbyHYY
Slide 21 : CC Dan Crile licence Unsplash https://unsplash.com/fr/photos/un-homme-travaillant-sur-un-moteur-de-voiture-dans-un-garage-EJr3XkHdBm0
Slide 36 : CC Michał Parzuchowski licence Unsplash https://unsplash.com/fr/photos/garcon-en-livre-de-lecture-de-sweat-a-capuche-gris-et-rouge-BPXSTl_HBhk
Slide 38 : CC Bharath Kumar licence Unsplash https://unsplash.com/fr/photos/un-tas-de-visages-souriants-sur-une-surface-blanche-zdbzfBiQKOg
Slide 44 : CC Rashni Parichha licence Unsplash https://unsplash.com/fr/photos/un-chat-baille-assis-sur-un-canape-oeQArN-ib3U