Mon père a 70 ans et utilise une application tous les jours — voici comment on la construit

Le problème n'est pas l'âge

On dit volontiers que « les personnes âgées ne s'en sortent pas avec la technologie », et c'est presque toujours faux. Quelqu'un qui a grandi sans ordinateur a appris à conduire, à tenir un foyer, à remplir des formulaires et à affronter l'administration — autant de systèmes bien plus compliqués qu'une application. Ce qu'il n'a pas appris, et c'est bien normal, c'est à deviner. Il ne suppose pas que trois petits points dans un coin cachent un menu, qu'un glissement sur le côté efface quelque chose, ni que le bouton descendu hier en bas de l'écran est toujours le même bouton.

Le logiciel ordinaire est construit sur l'idée que l'utilisateur devinera juste et, sinon, qu'il réessaiera. Celui qui n'aime pas la technologie ne réessaie pas. Il ferme, et ne revient pas. À ses yeux, l'échec est celui de l'outil, pas le sien — et il a raison. La bonne question n'est donc pas de savoir comment lui apprendre à s'en servir, mais comment construire quelque chose où il n'y a rien à apprendre.

La différence entre utilisateurs jeunes et âgés est réelle, mais elle tient moins aux compétences qu'à la patience face à ce qui n'est pas clair. Le W3C, qui fixe les normes d'accessibilité du web, souligne qu'une grande partie des besoins des utilisateurs âgés — la vue, la précision du toucher, la mémoire immédiate — recoupe les besoins d'accessibilité en général. Autrement dit, ce que l'on construit pour eux améliore les choses pour tout le monde.

Le critère de réussite : qu'il n'appelle jamais pour demander

Avant d'écrire la moindre ligne de code, nous avons décidé à quoi ressemblerait la réussite. Ni un nombre de fonctions, ni un design, ni « il a dit que c'était joli ». La réussite a été définie ainsi : une semaine après avoir reçu l'application, il s'en sert tous les jours — et n'appelle jamais pour poser une question.

Le critère paraît modeste, il est en réalité exigeant. Tout écran qui suscite une question échoue. Tout message d'erreur qui contient le mot « serveur » échoue. Tout bouton qui fait deux choses différentes selon le contexte échoue. Et surtout, il écarte d'emblée la réponse commode, « on lui fera une formation ». Une formation, c'est l'aveu que l'outil ne s'explique pas tout seul ; nous l'avons développé dans notre article sur le logiciel qui se passe de formation.

Sept règles apprises d'une seule application

1. Un écran, une action. L'application fait une chose : elle enregistre une dépense. Quand on l'ouvre, la première chose qu'on voit, c'est l'endroit où la noter — pas un menu, pas un tableau de bord, pas un « bienvenue ». Tout ce qui n'est pas cette action n'est tout simplement pas sur son écran.

2. Pas de mot de passe à la porte. Pour la plupart des utilisateurs âgés, un mot de passe oublié signe la fin d'une application : ils ne le réinitialiseront pas et ne toucheront pas « mot de passe oublié ». L'application s'ouvre depuis un lien personnel installé sur l'écran d'accueil, et la sécurité se joue en coulisses — pas comme une corvée à accomplir chaque matin.

3. Ses mots, dans sa langue. Pas « catégorie », pas « synchronisation », mais les mots qu'il emploie lui-même quand il parle de la dépense. Et toute l'interface est dans sa langue maternelle, même si le développeur pense dans une autre. Chaque mot qu'il faut traduire dans sa tête est une occasion de plus de s'arrêter.

4. Un bouton ne bouge pas. Une nouvelle version qui déplace un bouton — même pour le mieux — efface ce que la main savait déjà. Chez lui, chaque changement passe un seul contrôle : ce qui était à tel endroit hier y est-il encore aujourd'hui ?

5. Vraiment grand, pas « assez grand ». Le bouton d'action occupe presque toute la largeur de l'écran, et le texte est net et bien contrasté. La norme d'accessibilité WCAG 2.2 fixe une taille minimale pour les zones tactiles — c'est le plancher d'où l'on part, pas l'objectif.

6. Une confirmation qui se voit. Après l'enregistrement, l'écran dit clairement que c'est enregistré, et montre ce qui l'a été. Celui qui n'est pas sûr que l'action a fonctionné la refera — et voilà des doublons — ou appellera pour demander. Dans les deux cas, c'est l'interface qui a échoué, pas l'utilisateur.

7. Le pardon plutôt que « Êtes-vous sûr ? ». Une fenêtre de confirmation avant chaque action apprend à toucher « Oui » sans lire. Mieux vaut permettre de corriger facilement après une erreur que d'effrayer avant d'agir.

Ce que nous avons refusé d'ajouter

Le plus difficile, dans la construction de l'application, n'a pas été de décider quoi y mettre, mais quoi laisser dehors. Chaque idée avait du sens — des graphiques par mois, des rappels, un écran de réglages, un historique avec recherche — et à peu près la moitié de ce à quoi nous avions pensé n'y est jamais entrée.

Ces idées n'ont pas été écartées parce qu'elles étaient mauvaises. Elles l'ont été parce que chacune lui aurait donné une chose de plus à regarder, un endroit de plus où toucher par erreur, et une raison de plus de décrocher le téléphone. Un graphique est formidable pour qui analyse ; pour qui veut juste noter une dépense, c'est du bruit. Et celui qui a besoin de la vue d'ensemble l'obtient de l'autre côté : la personne qui tient les comptes reçoit un classeur Excel bien rangé, sans que mon père en voie jamais une ligne. La complexité n'a pas disparu — elle est allée là où quelqu'un la veut.

Nous avons longuement écrit sur le prix de chaque « juste un petit bouton de plus » dans plus de fonctions, plus de désordre.

Simple dehors, du travail dedans

On a tendance à croire qu'une application à un seul bouton est facile à construire. C'est l'inverse. Pour que l'utilisateur n'ait pas à réfléchir, quelqu'un d'autre doit réfléchir à sa place, à l'avance : que se passe-t-il quand le réseau faiblit en plein enregistrement, quand on appuie deux fois, et comment la photo d'un ticket arrive au bon endroit, sous un nom que quelqu'un saura encore retrouver dans un an ?

Chacune de ces questions est une décision d'ingénierie, et aucune ne se voit à l'écran. C'est cela, la simplicité comme accomplissement : pas moins de travail, mais un travail que l'utilisateur n'a jamais à voir. Son prix se paie une fois, à la construction — et non chaque jour, en coups de téléphone.

Et pourquoi cela concerne votre entreprise

Vous n'avez peut-être pas de parent qui a besoin d'une application. Mais presque chaque entreprise compte quelqu'un pour qui le logiciel doit aussi fonctionner : le salarié qui fait son métier à merveille depuis vingt ans, la cliente qui remplit un formulaire une fois par an, le chef de chantier qui fait son rapport depuis le terrain au milieu d'une longue journée. Ils ne sont pas « nuls en informatique ». Ils sont simplement occupés à autre chose.

Les questions sont les mêmes : quelle est la tâche unique qu'il doit accomplir, comment l'appelle-t-il, et que se passe-t-il quand il se trompe ? Un logiciel qui y répond bien servira tout le monde, y compris ceux qui aiment la technologie — personne ne se vexe qu'une chose marche sans effort. Et si vous hésitez entre ce qui entre et ce qui reste dehors, nous avons détaillé le calcul sur plusieurs années dans combien coûte vraiment un site ou une application à entretenir.

Y a-t-il chez vous quelqu'un — salarié, client ou parent — pour qui le logiciel actuel ne fonctionne tout simplement pas ? Écrivez-nous en deux lignes qui il est et ce qu'il doit faire dans une journée ordinaire — et nous vous dirons honnêtement si l'on peut simplifier.