Vous connaissez la persona ? Pour ma part, j’avais initialement cru que ce concept venait du monde de la publicité, pour finalement découvrir qu’il a été décrit par Alan Cooper dans son livre « The Inmates Are Running the Asylum » publié en 1998. Alan est un informaticien, il est notoirement connu pour être à l’origine du langage de programmation Visual Basic à la fin des années 90. Ce n’est pas un hasard, il s’est très tôt intéressé à révolutionner l’approche de construction des logiciels, selon lui trop orientée sur le code et pas assez sur les besoins des utilisateurs.

Alan avait d’ailleurs pris l’habitude d’interroger les utilisateurs des produits de ses clients pour découvrir les dénominateurs communs qui rendaient les gens heureux. A ce stade, ses enquêtes de terrain relèvent quasiment d’une démarche ethnographique. C’est à ce moment-là que la persona est naît comme un outil de conception, en tant qu’archétype d’utilisateurs possibles du logiciel développé. Alan créera par la suite la méthode de « Conception orientée objectif », basée sur le fait que le logiciel devrait accélérer l’utilisateur vers son objectif ultime plutôt que de l’emprisonner dans les menus détails de son ordinateur.

Depuis, le concept de persona est devenu très populaire en Agilité (les écrits de Roman Pichler m’ont beaucoup aidés) même si je me désole encore aujourd’hui de sa sous-utilisation voire de sa méconnaissance de la part des responsables produits et product owners.


Pour ma part, je l’utilise le plus souvent possible. Un exemple trivial ? Un client me demande comment (apprendre à) découper un traitement comptable d’un point de vue fonctionnel pour alimenter le backlog produit. J’ai parié avec lui que j’arriverai à lui donner des pistes en le questionnant sur les personas :

  • Qui émet quotidiennement les 200 000 créances ? La persona du Comptable émerge (cas nominal de fonctionnement).
  • Qui demande à ré-émettre une créance pour équilibrer la comptabilité ? La persona du Contrôleur comptable émerge, avec l’idée d’une fonctionnalité d’auto-diagnostic quotidien et d’une fonctionnalité de recyclage des rejets mise à disposition de la persona Assistant au support client.
  • Qui fait la reprise des 1 000 000 de créances passées ? La persona du Déployeur émerge avec une sacré contrainte de performance / délai sur l’installation de la nouvelle version chez son client.
  • Qui garantit que la journée comptable J+1 ne commencera pas tant que les créances de la journée comptable J n’ont pas été préalablement validées. Encore la persona du Contrôleur comptable, avec sans doute la contribution de la persona Pilote d’exploitation qui publie chaque matin à 8h30 un bulletin météo.
  • … et oui, l’Assistant au support client, le Déployeur et le Pilote d’exploitation, ces éternels oubliés, ont bien une utilisation particulière de votre logiciel, le plus souvent lié à des contraintes d’intégrité, déployabilité, exploitabilité, …

Je pense que vous voyez l’idée. Mon client était sur le point de rédiger une unique user story intitulée « Émettre les créances quotidiennement » sans recourir à la persona, ben oui ça passera bien dans un sprint de 4 semaines. Et tout d’un coup il se retrouve avec 5 personas et 7 grosses user stories candidates à affiner, mais avec une estimation de la charge plus pertinente, une première identification des risques, et surtout un début de tactique pour « démontrer » une première version de ce traitement. Je ne vous parlerai pas du fait que l’on puisse créer, mettre à jour et supprimer des créances et qu’il existe différents types de créance, ce qui crée une combinatoire intéressante pour découper plus finement les user stories, mais c’est une autre histoire…


En fait, ce n’est pas de cela que je voulais vous parler. J’utilise aussi les personas dans ma préparation. Vous les aviez sans doute vu émerger lors de ma préparation des Coach Clinic aux ScrumDayFr 2014 et 2015, ainsi qu’aux Agile Tour 2014 de Rennes, Monpellier et Bordeaux.

Je les utilise maintenant lorsque je prépare des formations en intra-entreprises. J’ai eu ma période où je déroulais mes propres exemples lors de la formation, ce qui pouvait créer des fossés sémantiques avec le métier de mon client, et qui l’invitait à résoudre des problèmes qu’il n’avait pas.

Aujourd’hui, je préfère carrément demander à mon client deux ou trois cas d’étude intéressants (un projet passé ? une maintenance évolutive ? une nouvelle offre ?) et à travailler avec ce fil rouge lors de la formation, généralement 3 jours c’est bien pour faire un « Vis ma vie » agile. Je vais encore plus loin, je demande à rencontrer les participants ou j’envoie un formulaire d’enquête pour identifier différents types de demande. L’enquête peut commencer par des questions du type : 

Quel est votre parcours ?

  • Vous venez du Métier (user) ?
  • Vous êtes tombé dans l’IT tout petit (geek) ?
  • Vous venez d’une autre galaxie (alien) ?
  • Autre :

Dans la gestion des produits, vous êtes plutôt impliqué(e) dans :

  • La lancement de nouveaux produits (esprit startup) ?
  • La maintenance de produits existants (clients fidélisés) ?
  • Autre :

Quelles sont vos frustrations ?

  • Avec le Projet :
  • Avec le Produit :
  • Avec le Client :
  • Autre :

… et ainsi de suite.

Ce qui me permet de commencer à dessiner ce type de personas :

Persona Laurent

Persona Charles

Persona Anne

Ce type de travail me permet de construire l’alliance avec le groupe à former avant même le début de la formation et, évidemment, de personnaliser le contenu de la formation.


Un autre exemple ? Dans le coaching de managers, je pense souvent à Adèle, c’est une persona que je rencontre souvent :

Persona Manager

Journée-type de la Persona Manager

Une bonne cliente pour la prochaine formation Facilitation d’équipe à Bordeaux. Ca me rappelle qu’une bonne persona est une persona qui crée de l’émotion. Lorsque je réfléchis à mon client à travers la persona, je fais un acte d’empathie. Un bon début pour persona-liser vos services 🙂

Source de l’image : Persona et conception orientée objectif