Title, ce faux ami de l’accessibilité
Le 21 décembre 2013, Romy Duhem-Verdière nous expliquait déjà dans les vingt-quatre jours du web pourquoi il fallait utiliser avec modération l’attribut title - ouvre une nouvelle page.
Près de quinze ans plus tard, le constat reste similaire : l’attribut title continue d’être employé à mauvais escient. À l’occasion des douze ans de publication de cet article, je souhaite revenir sur ce sujet, car en accessibilité il est souvent nécessaire de répéter et de reformuler pour ancrer les bonnes pratiques.
Mais reprenons les choses au début.
L’attribut title, à quoi ça sert ?
Selon la définition de Mozilla Developer Network (MDN), l’attribut universel title contient un texte d’information lié à l’élément auquel il est rattaché1
.
Historiquement, l’attribut title est utilisé pour afficher des infobulles, fournir un nom accessible à un élément, ou les deux.
Afficher une infobulle
Si l’on survole avec une souris un élément avec un attribut title, au bout d’un instant, le contenu de l’attribut title apparaît dans un cadre flottant à proximité de l’élément.
C’est principalement utilisé pour préciser la signification d’une icône ou d’un pictogramme, ou encore pour ajouter des informations complémentaires utiles à la compréhension.


Fournir un nom accessible
L’autre usage courant consiste à fournir un intitulé accessible à un élément interactif (lien, bouton, champ de formulaire, etc.). Cette technique est reconnue comme conforme par le Référentiel général d’amélioration de l’accessibilité (RGAA).
Par exemple, le nom accessible d’un lien est déterminé selon l’ordre suivant :
- texte associé via
aria-labelledby; - sinon, contenu de l’attribut
aria-label; - sinon, contenu textuel du lien ;
- sinon, contenu de l’attribut
title.
Source : Intitulé (ou nom accessible) de lien sur le site du RGAA - ouvre une nouvelle page
Exemple d’utilisation de l’attribut title pour donner un nom accessible à un lien contenant uniquement un pictogramme :
<a href="https://exemple.com/espace-personnel" title="Espace Personnel">
<span aria-hidden="true" class="fa-solid fa-user"></span>
</a>
Exemple d’utilisation de l’attribut title pour donner du contexte supplémentaire à un lien contenant déjà un texte :
<a href="https://exemple.com/mentions-legales" title="Mentions légales - ouvre une nouvelle page">
Mentions légales
</a>
C’est quoi le problème ?
Limites de l’utilisation de l’attribut title pour afficher une infobulle
L’information est cachée et nécessite de deviner son existence
Si vous utilisez cette technique pour expliciter la signification de votre icône, c’est comme si vous jouez aux devinettes avec vos utilisateurs et vos utilisatrices.
Rien n’indique a priori aux personnes qu’une infobulle est disponible. Elles doivent tester : Tiens, et s’il se passait quelque chose si je survole cette icône avec ma souris ?
.
Zone avec six pictogrammes, le cinquième pictogramme est un chat et possède un attribut title « Miaou ! ».
Les textes des attributs title obligent à patienter
Admettons que les personnes qui visitent votre site soient fans d’escape game : elles pourraient tenter l’expérience, mais alors, elles devront attendre… car l’apparition de l’infobulle n’est pas instantanée.
Transcription
Présente un extrait de page web. La zone comporte six pictogrammes. Lorsque la souris passe sur le cinquième, qui représente un chat, une infobulle affichant le texte « Miaou ! » apparaît après un court délai.
Sensible au moindre mouvement
Et pour se voir récompensés par l’apparition d’une infobulle, ils devront être adroits : ils vont devoir introduire le curseur de leur souris dans la zone exacte de l’élément qui la porte, et y laisser leur souris sans bouger : l’infobulle n’apparaît que si la souris est parfaitement immobile. Et si vous déplacez votre souris, elle disparaît.
Transcription
Présente un extrait de page web contenant une phrase où l’abréviation « API » est soulignée en pointillé.
La souris passe dessus mais reste en mouvement, ce qui n’entraîne aucune action. Lorsqu’elle se stabilise suffisamment longtemps, une infobulle affichant « Application Programming Interface » apparaît. Toutefois, le message disparaît dès que la souris bouge légèrement, même si elle reste dans la zone de l’abréviation.
Cela crée une barrière pour les personnes qui ne peuvent pas manipuler la souris avec précision.
L’infobulle n’est pas adaptable
Certaines personnes ont besoin d’agrandir le texte, d’augmenter le contraste, d’utiliser un thème sombre ou des feuilles de style personnalisées. Or, l’infobulle générée par l’attribut title ne respecte ni le zoom, ni le thème, ni les styles appliqués par les personnes concernées.
Transcription
Présente un extrait de page web en mode clair, contenant un lien intitulé « Connexion à l’espace professionnel ».
Lorsque la souris se stabilise, une infobulle affichant le même texte apparaît.
L’écran est ensuite zoomé : la taille du texte double, mais celle de l’infobulle reste inchangée et ne s’adapte pas. Le thème de la page passe ensuite en mode sombre ; l’ensemble de l’interface bascule alors en sombre, sauf l’infobulle qui reste claire.
Les textes des infobulles ne sont pas sélectionnables
Le contenu des infobulles générées par l’attribut title ne peut pas être sélectionné ni copié.
Inaccessible au clavier
Cela exclut également les personnes qui naviguent uniquement au clavier. Les infobulles générées par l’attribut title ne sont pas accessibles via le clavier, même sur un lien ou un élément interactif.

Inutilisable sur tablettes et smartphones
Si la navigation se fait sur une tablette ou un smartphone, il est impossible d’afficher les infobulles générées par l’attribut title.
Cela signifie que toute information uniquement présente dans cette infobulle sera totalement inaccessible sur ces terminaux.

Problèmes liés à l’utilisation de l’attribut title pour donner un nom accessible
L’utilisation de l’attribut title pour fournir un nom accessible vise principalement les personnes naviguant avec un lecteur d’écran. Bien que cette technique soit considérée comme valide par le RGAA, elle présente plusieurs limites et problèmes d’accessibilité.
Lecture aléatoire par les lecteurs d’écran selon le contexte et les réglages
Le principal problème est que l’attribut title n’est pas toujours restitué par les lecteurs d’écran2
.
Par exemple, avec NVDA, le texte des attributs title présents sur un lien ou un bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page :
Transcription
Un extrait de page web contient le texte : « Par exemple, avec NVDA, le texte des attributs title présents sur un lien ou un bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page. »
Dans ce texte, « lien » est un lien et « bouton » est un bouton. La navigation commence par un déplacement d’un élément interactif à l’autre : le lecteur vocalise le contenu des éléments et leurs title. Ensuite, la navigation se fait de façon linéaire : seul l’intitulé visible est vocalisé.
Texte prononcé par le lecteur d’écran :
« lien, visité, même page, lien – Ce lien possède un attribut title avec du texte
bouton bouton – Ce bouton possède un attribut title avec du texte
Par exemple, avec NVDA, le texte des attributs title présents sur un visité, même page, lien lien ou un bouton bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page. »
Risque de répétitions
Lorsque vous utilisez un attribut title sur un lien qui contient déjà du texte (par exemple pour ajouter du contexte), il existe un risque de doublon.
Selon la configuration des lecteurs d’écran, le contenu du title et le texte du lien peuvent être vocalisés. Ce n’est pas bloquant, mais cela ralentit la lecture, augmente la charge cognitive et allonge le temps de restitution…
Transcription
Un extrait de page web présente un titre intitulé « Informations légales », suivi d’une liste de liens :
- Charte avis en ligne
- Données personnelles
- Informations sur les cookies
- Conditions générales de réparation du service après-vente en magasins
- Rappel produits
- Notifier un contenu illicite / sécurité
- Accessibilité : non conforme
- Digital Service Act
Lors de la navigation avec un lecteur d’écran, chaque lien est annoncé deux fois : la seconde occurrence comporte le suffixe « nouvelle fenêtre ». La souris survole ensuite deux liens pour montrer que ces secondes occurrences correspondent au contenu du title associé à ces liens.
Texte annoncé par le lecteur d’écran :
« liste de 9 éléments
Charte avis en ligne, lien
Charte avis en ligne (nouvelle fenêtre)Données personnelles, lien
Données personnelles (nouvelle fenêtre)Informations sur les cookies, lien
Informations sur les cookies (nouvelle fenêtre)Conditions générales de réparation du service après-vente en magasins, lien
Conditions générales de réparation du service après-vente en magasins (nouvelle fenêtre) »
Le pire, c’est lorsque l’attribut title reprend exactement la même information que celle déjà présente dans le lien.
Problèmes de traduction et de prononciation
Certains navigateurs proposent une fonctionnalité de traduction qui ne fonctionne pas sur le contenu des attributs title.
Certains lecteurs d’écran ne respectent pas la langue définie dans la page et lisent le texte du title avec la voix par défaut du système.
title pour un bouton et un lien, affichée sur un poste configuré en françaisTranscription
Extrait d’une page web : cette page est en anglais et contient un bouton ainsi qu’un lien.
La navigation commence par un survol des éléments interactifs pour afficher des infobulles :
- « Text explaining the button’s role placed in a title attribute » pour le bouton ;
- « Text explaining the link’s role placed in a title attribute » pour le lien.
Ensuite, le lecteur d’écran lit le texte avec une voix anglaise et un accent impeccable.
Puis, lors de la navigation entre les éléments interactifs, la voix passe en français avec un accent français, ce qui rend la compréhension difficile.
Texte prononcé par le lecteur d’écran :
Voix anglaise : Example of a page in English (the HTML tag includes a lang="en" attribute). The screen reader pronounces the technical elements in the user’s language (French in this example) and reads the text using the language defined by the page (English). If an element contains a title attribute, like this
Voix française : bouton
Voix anglaise : button
Voix française : bouton Text explaining the button’s role placed in a title attribute
Voix anglaise : link
Voix française : visité même page lien Text explaining the button’s role placed in a title attribute. visité même page lien
Voix anglaise : link. it is pronounced with a French accent
Risque d’inaccessibilité avec les logiciels de commande vocale
Une des techniques principales pour activer un lien via un logiciel de commande vocale est de prononcer le texte du lien, par exemple : « cliquer sur François-Xavier Lair ».
Si le contenu de l’attribut title ne reprend pas ce texte, il existe un risque que le lien ne puisse pas être activé par commande vocale, ce qui rend la navigation impossible pour les personnes utilisant ces assistances.
Exemple avec un lien de connexion ayant un title « Espace personnel » et un texte visible « François-Xavier Lair » :

<a href="https://exemple.com/espace-personnel" title="Espace Personnel">
<span aria-hidden="true" class="fa-solid fa-user"></span>
François-Xavier Lair
</a>
En résumé, l’attribut title est non seulement totalement inaccessible pour toutes les personnes qui naviguent au clavier, sur tablette ou sur smartphone, mais il présente également des difficultés pour de nombreux usages et profils.
Quelles solutions pour remplacer l’attribut title ?
Après avoir passé en revue l’ensemble des limites et des risques liés à l’attribut title, une question se pose naturellement : par quoi le remplacer ?
Dans cette deuxième partie, nous allons présenter les principales solutions, leurs avantages, ainsi que les points de vigilance à garder en tête pour garantir une accessibilité optimale.
Fournir un texte accessible
aria-label ?
L’attribut aria-label - ouvre une nouvelle page peut remplacer title, mais il présente aussi plusieurs limites :
- problèmes de traduction : comme pour
title, certains navigateurs ne traduisent pas le contenu de l’attributaria-label. - remplacement du texte visible :
aria-labelsubstitue le texte affiché, ce qui peut entraîner les mêmes risques quetitle(nom accessible différent du texte visible). - problèmes de maintenance : intégré directement dans le HTML,
aria-labelpeut être oublié lors des mises à jour. De plus, toutes les personnes impliquées dans la production ne maîtrisent pas les mécanismes de génération du nom accessible.
Il est également important de rappeler un principe clé d’ARIA : il est recommandé de privilégier les solutions natives en HTML plutôt que d’ajouter des attributs ARIA lorsqu’ils ne sont pas nécessaires3 .
Pour approfondir le sujet, Eric Bailey l’explique en détail dans son article intitulé aria-label is a code smell - ouvre une nouvelle page.
Utiliser du texte masqué visuellement
C’est la solution la plus fiable. Elle consiste à ajouter un texte caché visuellement, mais correctement restitué par les lecteurs d’écran.
Pour cela, on utilise une classe de masquage accessible — souvent nommée visually-hidden ou sr-only — comme celles proposées par Bootstrap4
ou ffoodd5
.
<a href="https://exemple.com" class="icon-link">
<span class="visually-hidden">Accéder à la page d’exemple</span>
<svg aria-hidden="true" focusable="false" width="24" height="24">
<!-- Icone SVG -->
</svg>
</a>
Ainsi, le texte est intégré directement au contenu de l’élément HTML qu’il complète, garantissant une sémantique claire et évitant les problèmes liés à l’utilisation de title ou aria-label.
Infobulles
Passons maintenant aux méthodes permettant de remplacer l’utilisation de l’attribut title pour créer des infobulles.
Rendre l’information visible d’emblée
La solution la plus simple et la plus efficace consiste à ne pas utiliser d’infobulles : affichez l’information directement.
Souvent, l’infobulle n’est qu’une tentative de rattrapage d’un pictogramme ambigu.
Si vous pensez devoir préciser le rôle d’un pictogramme ou d’une icône via un attribut title, pourquoi ne pas l’afficher clairement ?
Combien de fois vous êtes-vous demandé : « Quel est le rôle de ce bouton ? » Combien de fois avez-vous cliqué sur un bouton composé uniquement d’un pictogramme, pour constater que l’action n’était pas celle attendue ?
Par exemple, savez-vous à quelles actions correspondent les deux icônes ci-dessous ?
Réponse
Selon l’article de LogRocket – Which icons to NOT use in 2025 - ouvre une nouvelle page :
- le premier symbole représente des dossiers ;
- le second indique l’action de synchroniser les données entre les appareils et le cloud, sauvegarder.
Si vous connaissiez la réponse, pensez-vous que votre mère l’aurait su ? Et votre grand-mère ?
Un pictogramme peut sembler évident… mais pas pour tout le monde. Parfois, c’est culturel6 .
S’il vous plaît, mettez des labels à vos icônes.
Dans le même ordre d’idée, si vous utilisez des infobulles pour fournir un contexte supplémentaire, demandez-vous si cette information ne devrait pas être affichée directement, sans passer par un mécanisme caché.
Popover
Si l’usage d’une infobulle est vraiment nécessaire, autant le faire avec les éléments HTML dédiés.
L’API Popover est un nouveau standard qui permet d’afficher du contenu en superposition par rapport au reste de la page. Ce contenu peut être contrôlé à l’aide d’attributs HTML ou via JavaScript.
Implémentation de base
Placez le texte à afficher dans un élément avec l’attribut popover et un identifiant unique pour pouvoir le cibler :
<div popover id="toggletip">
A11y est un acronyme numérique pour <span lang="en">Accessibility</span> (accessibilité en anglais)
</div>
Ensuite, utilisez un élément <button> relié à ce premier élément grâce au nouvel attribut popovertarget. Cet attribut doit contenir l’id de l’élément cible :
<button type="button" popovertarget="toggletip">
A11y
</button>
Le popover s’affiche lorsque vous actionnez le bouton.
La touche Échap est même prise en charge pour fermer le popover.
Tester l’implémentation de base sur CodePen - ouvre une nouvelle page.
Gestion de la sémantique
L’attribut popover n’a pas de rôle intégré. Après tout, ce n’est pas un élément. Son objectif est uniquement d’ajouter un comportement de popover et peut être appliqué sur différents types d’éléments (menu, dialogue, notifications de type toast, etc.).
Il est donc nécessaire de lui attribuer un rôle. Le rôle le plus approprié est tooltip.
Cependant, ce rôle n’est pas encore pris en charge par les lecteurs d’écran. Il est donc nécessaire d’ajouter un attribut aria-describedby pour que le contenu du popover soit correctement restitué.
<button type="button" aria-describedby="toggletip" popovertarget="toggletip">
A11y
</button>
<div popover role="tooltip" id="toggletip">
A11y est un acronyme numérique pour <span lang="en">Accessibility</span> (accessibilité en anglais)
</div>
Gestion de la souris et du clavier
Pour reproduire le comportement attendu d’une infobulle, il est nécessaire d’ajouter un peu de JavaScript afin de gérer son affichage au survol de la souris.
const trigger = document.querySelector(’[popovertarget]’);
const tooltip = document.querySelector(’[popover]’);
// Gestion souris
trigger.addEventListener(’mouseover’, tooltip.showPopover());
trigger.addEventListener(’mouseout’, tooltip.hidePopover());
// Gestion clavier
trigger.addEventListener(’focusin’, tooltip.showPopover());
trigger.addEventListener(’focusout’, tooltip.hidePopover());
Cela permet également de corriger l’un des problèmes des infobulles générées via l’attribut title : l’absence d’affichage lors de la navigation au clavier.
L’API Popover met à disposition les méthodes showPopover et hidePopover pour cela.
Tester sur CodePen l’exemple de popin avec un JavaScript de base - ouvre une nouvelle page.
Personnalisation des styles et du comportement
Par défaut, le popover s’affiche centré dans la fenêtre.
Pour reproduire le comportement classique des infobulles — affichage à proximité de l’élément déclencheur —, il faut ajouter un peu de CSS.
Ce type de placement a longtemps été complexe à gérer (superpositions, zoom, ajustement selon la taille de la fenêtre), mais le nouveau module CSS Anchor Positioning - ouvre une nouvelle page simplifie désormais grandement cette tâche.
Il permet de positionner un élément par rapport à un autre en définissant une ancre avec la propriété anchor-name et de placer un élément en s’y référant via position-anchor.
La propriété position-area détermine comment l’élément se positionne par rapport à son ancre (au-dessus, en dessous, à gauche, etc.), et il est même possible de définir des positionnements de secours si l’espace initial n’est pas disponible, grâce à la propriété position-try-fallbacks.
[popovertarget] {
anchor-name: --triger-tooltip;
}
[popover] {
overflow: visible;
position-anchor: --triger-tooltip;
position-area: top;
position-try-fallbacks: flip-inline, bottom, top;
}
Tester sur CodePen l’exemple de popin avec personnalisation des styles - ouvre une nouvelle page.
Ressource : tutoriel alsacréations Le positionnement par ancre : anchor positioning - ouvre une nouvelle page
Limitation actuelle : CSS Anchor Positioning n’est pas encore largement pris en charge en dehors de Chrome et Safari.
Il est donc nécessaire de prévoir une solution de secours en JavaScript pour gérer le positionnement.
La solution la plus simple consiste à utiliser une bibliothèque comme Floating UI - ouvre une nouvelle page.
Support
Le support de l’API Popover est désormais excellent. Elle est largement prise en charge par les principaux navigateurs d’après Can I Use - ouvre une nouvelle page.
Limites de la solution
L’objectif de cet article n’est pas de fournir une implémentation générique et totalement accessible d’infobulles, mais d’alerter sur les risques liés à l’attribut title.
Les extraits de code présentés ne doivent pas être utilisés tels quels en production : ils servent uniquement de base de réflexion.
Un point de vigilance concerne la manière dont l’information est restituée aux lecteurs d’écran. Grâce à l’attribut aria-describedby, la personne qui utilise un lecteur d’écran aura bien accès au contenu de l’infobulle. Cependant, cette information sera annoncée systématiquement, alors que le reste du public peut choisir d’afficher ou non l’infobulle.
Autre limite : le lecteur d’écran restitue cet élément comme un motif plié/déplié, en annonçant « développé » ou « réduit » lorsque le bouton est activé, alors même que le contenu associé n’est pas forcément contigu.
Exceptions
Il reste trois situations où l’attribut title demeure nécessaire.
Donner du contexte pour les étiquettes de formulaires dont le contenu n’est pas visible
Pour les champs de formulaire dont l’étiquette n’est pas visible ou n’est pas placée à proximité, le test 11.1.3 du RGAA - ouvre une nouvelle page recommande d’utiliser un attribut title afin de préciser la nature de la saisie attendue.
Exemple :
<label for="search-input-md" class="visually-hidden">Rechercher dans le site…</label>
<input placeholder="Rechercher dans le site…" title="Rechercher dans le site…" id="search-input-md" type="search" name="texte">
<button title="Rechercher" type="submit"><span class="fr-sr-only">Rechercher</span></button>
Nommer les iframes
L’attribut title reste aujourd’hui la méthode recommandée pour donner un nom à une iframe.
C’est une exigence de conformité du RGAA, le critère 2.1, qui impose que chaque iframe (balise <iframe> ou <frame>) ait un attribut title.
Dans ce cas précis, l’usage de title ne pose pas les mêmes problèmes, car :
- il sert uniquement de nom accessible pour les technologies d’assistance ;
- il n’est pas utilisé pour afficher une infobulle ;
- il ne génère pas d’ambiguïté avec un contenu visible.
Exemple :
<iframe title="Contenu publicitaire tiers" src="https://bb99d6a.safeframe.googlesyndication.com/" id="google_ads_iframe"></iframe>
C’est donc l’un des rares contextes où title reste une bonne pratique et une exigence de conformité.
Nommer les vidéos
Lors de la relecture de cet article par un collègue aveugle, il m’a remonté que lorsque l’on arrivait sur une vidéo, il y avait un bouton lecture mais aucune indication du contenu de la vidéo : cela manquait de contexte.
Pourtant, chaque vidéo disposait d’une légende placée sous le lecteur par l’outil de gestion du site, ce qui répond au critère 4.7 du RGAA. Cette situation illustre parfaitement que la conformité ne garantit pas automatiquement l’accessibilité.
Dans un premier temps, un attribut aria-labelledby a été ajouté pour référencer le titre de la vidéo, mais ce mécanisme est mal pris en charge par les lecteurs d’écran dans ce cas. Ironiquement, la solution a finalement consisté à ajouter un attribut title sur la balise video.
Cet exemple rappelle une règle essentielle : en accessibilité, rien ne remplace les tests avec de vrais usages et de vrais outils.
Conclusion
L’attribut title peut sembler pratique pour afficher des infobulles ou fournir un nom accessible, mais, sauf rares exceptions, il reste un faux ami de l’accessibilité.
- Il n’est pas fiable pour les lecteurs d’écran.
- Sa fonctionnalité d’infobulle ne fonctionne ni sur mobile ni sur tablette, et elle n’est pas accessible au clavier.
- Il pose des difficultés aux personnes naviguant sur votre site, qu’elles soient en situation de handicap ou non.
Privilégiez des solutions inclusives :
- Affichez l’information directement lorsque c’est possible.
- Sinon, utilisez des solutions basées sur les standards HTML.
Une infobulle ne doit jamais être indispensable pour comprendre ou utiliser une interface. L’accessibilité repose sur la clarté, la visibilité et la compatibilité avec toutes les technologies d’assistance.
Pour l’année 2026 qui commence bientôt, prenez une bonne résolution : laissez l’attribut title derrière vous et adoptez des alternatives réellement accessibles pour toutes et tous.
Références
- Hampus Sethfors : Title Texts Suck et How icons are ruining interfaces
- Steve Faulkner : Using the HTML title attribute
- Powermapper.com : Comportement des attributs title dans les lecteurs d’écran couramment utilisés
- Julie Moynat : Le vaste monde des alternatives textuelles : l’attribut title
- Julie Moynat : Un lien qui s’ouvre dans une nouvelle fenêtre ou onglet accessible
- Sarah Higley : Tooltips in the time of WCAG 2.1
- Heydon Pickering : Tooltips & Toggletips
- Hidde de Vries : Semantics and the popover attribute: which role to use when?
- Scott O’Hara : a11y_tooltips
- Daniela Kubesch : PSA: Stop using the title attribute as tooltip!
- Chris Coyier : Using the Popover API for HTML Tooltips
-
Source : L’attribut
titlesur MDN - Ouvre une nouvelle page. Retour au texte 1 - Sa restitution dépend du paramétrage du lecteur, du mode de navigation et du contenu textuel du lien - ouvre une nouvelle page. Retour au texte 2
- Voir la règle n°1 d’ARIA sur le site du W3C - ouvre une nouvelle page. Retour au texte 3
- Mixin _visually-hidden.scss - ouvre une nouvelle page. Retour au texte 4
- Masquage accessible de pointe - ouvre une nouvelle page. Retour au texte 5
- Même l’icône de menu « hamburger » n’est pas comprise par tout le monde - ouvre une nouvelle page. Retour au texte 6
Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue :