Des utilisateurs souvent absents du cadrage
La plupart des projets démarrent avec un cahier des charges qui décrit ce qu’il faut livrer, un budget qui fixe les limites et un planning qui structure les étapes. Ce qui manque souvent, c’est une représentation claire de ceux pour qui le livrable est construit. On parle d’“utilisateurs finaux” dans les documents de cadrage comme d’un bloc homogène, alors que derrière ce terme générique coexistent des personnes aux compétences, aux attentes et aux contraintes très différentes.
Les personas, ces profils fictifs mais fondés sur des données réelles qui représentent des groupes d’utilisateurs types, offrent un moyen concret de combler cette lacune. Formalisé par Alan Cooper dans les années 1990 pour la conception d’interfaces logicielles, l’outil a depuis été adopté dans des contextes variés, du service public à l’industrie, dès lors qu’un projet implique des utilisateurs finaux.
Ce que les personas apportent au cadrage
Lors de la phase de cadrage, les décisions structurantes se prennent souvent sur la base de ce que le commanditaire imagine des besoins utilisateurs. Cette imagination, même bien intentionnée, est filtrée par la position hiérarchique, l’expérience passée et les priorités stratégiques du moment, ce qui peut créer un décalage avec la réalité du terrain.
Prenons l’exemple d’une mairie qui lance un projet de dématérialisation de ses démarches administratives. Le directeur général des services voit le projet sous l’angle de l’efficacité: réduire les files d’attente et les coûts de traitement. En construisant deux ou trois personas à partir d’entretiens avec les usagers et les agents d’accueil, l’équipe projet découvre des besoins que le cadrage initial n’avait pas anticipés.
Mireille, 72 ans, retraitée, se déplace au guichet parce qu’elle ne fait pas confiance aux formulaires en ligne et a besoin d’un interlocuteur qui confirme que sa demande a bien été prise en compte. Karim, 35 ans, artisan, veut pouvoir faire ses démarches depuis son téléphone entre deux chantiers, sans avoir à scanner des documents. Ces deux profils impliquent des choix de conception radicalement différents: une interface simple avec un accusé de réception visible pour l’un, une application mobile avec capture photo pour l’autre.
Arbitrer les priorités grâce aux personas
L’une des contributions les plus concrètes des personas intervient lors de l’arbitrage des exigences. Quand le budget ou le calendrier impose de réduire le périmètre, la question “quelles fonctionnalités supprimer?” se transforme en “quels utilisateurs accepte-t-on de moins bien servir?”, une formulation qui rend les conséquences des choix beaucoup plus visibles.
Le Nielsen Norman Group recommande d’identifier un persona principal, celui dont les besoins doivent être satisfaits en priorité, même si cela implique des compromis pour les autres profils. Dans l’exemple de la mairie, si les données montrent que 60% des usagers correspondent au profil de Mireille, la priorité ira à une interface web accessible et rassurante plutôt qu’à l’application mobile de Karim, qui pourra être développée dans une phase ultérieure.
Cette approche évite un piège classique du cadrage: construire un livrable qui tente de satisfaire tout le monde simultanément et qui, par excès de compromis, ne satisfait pleinement personne.
Les personas dans la spécification et la validation
Au-delà du cadrage, les personas structurent la rédaction des exigences fonctionnelles. Plutôt que d’écrire “le système doit permettre de soumettre une demande en ligne”, une exigence rédigée à travers le prisme d’un persona devient: “Mireille doit pouvoir soumettre sa demande en moins de cinq étapes, avec un message de confirmation clair à chaque étape.” La spécification gagne en précision sans recourir au jargon technique, ce qui facilite la validation par les parties prenantes non techniques.
Les personas servent également de grille de lecture lors des revues de livrables intermédiaires. Quand un prototype est présenté en comité, le chef de projet peut demander: “est-ce que cette interface fonctionne pour Mireille?” plutôt que de solliciter un avis général qui produit des retours vagues ou contradictoires. L’Interaction Design Foundation note que cette utilisation active des personas dans les décisions quotidiennes est ce qui distingue les équipes qui en tirent un bénéfice réel de celles qui les créent pour la forme.
Trois conditions pour que les personas servent le projet
Les personas ne sont pas un exercice documentaire: leur valeur dépend de la manière dont ils sont construits et utilisés.
La première condition est de fonder les profils sur des données terrain. Quelques entretiens avec des utilisateurs représentatifs produisent des personas bien plus utiles que des profils inventés en atelier. Le chef de projet qui consacre deux jours à rencontrer les futurs utilisateurs en début de projet récupère cet investissement tout au long du cycle de vie.
La deuxième condition est la parcimonie. Trois à cinq personas suffisent pour la majorité des projets. Au-delà, les profils deviennent trop proches les uns des autres pour guider des décisions distinctes, et l’équipe finit par les ignorer.
La troisième est la mobilisation continue. Un persona affiché au mur de la salle projet ne produit aucun effet s’il n’est pas explicitement convoqué dans les réunions de conception, les arbitrages de périmètre et les revues de livrables. L’IAPM insiste sur le fait que les personas doivent être traités comme des documents vivants, révisés aux jalons majeurs pour rester alignés avec l’évolution du projet et de ses utilisateurs.