Pourquoi partir des utilisateurs et non plus des besoins

27 novembre 2020

– 5 min de lecture

David Sevin

Nous le constatons encore aujourd’hui, certains projets n’aboutissent jamais, ou alors après des mois voire des années de mise en œuvre et sont boudés par les utilisateurs.

Malgré une gestion des changements, la plateforme n’est jamais utilisée et l’application meurt (on l’espère rapidement) sans jamais rencontrer ses utilisateurs.

Dans certains cas, le projet “stratégique” a été validé par la Direction, la technologie en haut à droite du cadran du Gartner a bien été déployée, mais au final les cas d’usage sont beaucoup trop compliqués à intégrer sur la plateforme. Ces projets finissent souvent en échec, les ressources ont été gaspillées et l’image de la DSI en pâtit.

Enfin, dans d’autres cas, l’étude s’éternise pour concevoir, et planifier l’architecture qui répondra à l’ensemble des cas d’usages et qui permettra de résorber la dette technologique. Ces cas de figure trop fréquents partent malheureusement de bonnes intentions. Il s’agissait de couvrir l’ensemble des besoins existants et d’absorber les besoins qui ne manqueront pas d’arriver à court et moyen terme.

Une approche frugale

La meilleure solution consiste à se concentrer sur quelques utilisateurs clés pour prendre en compte des fonctionnalités précises qui peuvent être implémentés sous forme de MVP en quelques sprints et le faire évoluer pour prendre en compte les nouveaux besoins.

L’architecture de la solution devra rester souple et prévoir “by design” de pouvoir intégrer de nouveaux composants et technologies qui répondront demain à des nouveaux besoins.

Pour réussir cette mise en œuvre, il faut donc réunir une équipe pluridisciplinaire qui sera en charge de :

Collecter et analyser les besoins des utilisateurs
Définir l’architecture fonctionnelle et de données
Définir l’architecture technique
Constituer et suivre la backlog
Concevoir et mettre en œuvre les développements
Déployer l’architecture technique

Au démarrage du projet il faudra donc :

un Product Owner
un architecte en charge des aspects fonctionnel, applicatifs et data
un architecte technique
un scrum master
un ou plusieurs développeurs spécialisés sur les stacks à mettre en oeuvre
un cloud-ops
Un Business Analyste

Une organisation efficiente

Cette organisation s’inspire des Pizza Teams (l’ensemble des membres d’une équipe doit pouvoir se nourrir sur une Pizza Américaine). Elle vise à simplifier la communication au sein d’une équipe. En effet, le nombre de liens entre les personnes d’une équipe peut être calculé avec la formule suivante (1) :

( N x (N -1 ) )/ 2

Où N est égale au nombre de personnes dans l’équipe.

Plus le nombre de personnes est important plus les échanges sont importants et les risques et le temps consacrés aux échanges sont importants.

La mobilisation de l’équipe permettra de produire au fil des sprints des versions de plus en plus abouties, revues régulièrement par les utilisateurs.

En quelques semaines, une première version pourra être déployée en production sur le périmètre jugé prioritaire par les utilisateurs.

L’adoption ne sera plus un problème, car les utilisateurs auront participé à la conception de leur outil et remonteront directement les fonctionnalités prioritaires.

Au fil des évolutions, l’équipe pourra être élargie pour prendre en compte des besoins impliquant des nouvelles briques d’architecture et de nouvelles technologies. Il faudra toutefois rester vigilant afin de ne pas dépasser le nombre critique de membres dans l’équipe.

Une dynamique dès le cadrage

Un cadrage initial est indispensable avant de lancer le projet. Certes l’organisation projet et le user-centrisme sont des facilitateurs, mais la clef dans le succès de la démarche se trouve en amont. Si au lieu de demander aux utilisateurs quels sont leurs besoins et de les hiérarchiser par priorités, nous leur demandions leurs envies ?

Les utilisateurs vont être concentrés sur ce qui est vraiment important dans leur travail et ce qui va leur simplifier la vie. Si l’application a de multiples utilisateurs, il faudra les amener à trouver un consensus et à présenter une liste commune. Cette liste sera la base de la backlog projet et devra être affinée afin de la rendre implémentable.

Faire adhérer les décideurs

Cette approche projet nécessite de rassurer les décideurs. En cela la méthode agile est insuffisante. Le burn out chart ou les autres indicateurs sont utiles au pilotage agile des projets, mais suffisent rarement à rassurer les décideurs sur les aspects coûts / délais / valeur ajoutée des projets.

Il faut donc trouver des indicateurs complémentaires, aptes à rendre compte de l’avancement des sprints, mais qui permettent aussi d’apporter de la visibilité aux décideurs qui n’ont que faire des points de complexités et autres idiomes agiles.

Revoir la méthode

La réussite des projets passe par une remise en question profonde de nos méthodes d’architecture. Le framework TOGAF nous donne de bonnes bases, mais elles sont loin d’être suffisantes pour aller vers de l’architecture SI agile.

Les évolutions de l’architecture découlant des besoins métiers et non plus d’une planification détaillée réalisée en début de projet et implémentée dans un cycle de plusieurs mois ou années, cela nous amène à adresser des problématiques qui remettent en cause nos méthodes de travail :

Les projets font de plus en plus souvent appel à de l’expérimentation. Les composants sont testés sur des calendriers resserrés et suivant l’adéquation par rapport au besoin, sont adoptés ou abandonnés.
Les schémas d’architecture initiaux sont vite obsolètes et ne seront maintenus qu’en contrepartie d’un investissement conséquent à faible valeur ajoutée pour l’utilisateur.
Les technologies évoluent (trop) vite, la maîtrise des technologies par les équipes de support et d’exploitation prend beaucoup plus de temps.
Les utilisateurs ne comprennent plus que l’informatique professionnelle soit décorrélées des technologies mises à dispositions par les GAFA.
Les projets sur plusieurs années sont obsolètes avant d’être ouverts aux utilisateurs.

Pourtant des méthodes et outils inspirés du design thinking, du Lean ou du manifeste agile sont là pour nous aider avec par exemple :

La méthode sprint pour l’expérimentation ;
Des outils de documentation automatique des architectures qui garantissent des schémas toujours à jour (2) ;
Une organisation devops et une automatisation du traitement des incidents ;
Une approche itérative des projets, pour apporter de la valeur aux utilisateurs de manière linéaire sans sacrifier la qualité.

Certains argumentent que ces transformations sont réalisables à l’échelle des startups ou de compagnies digital natives, mais c’est oublier que le dev-ops tire son origine du monde industriel, certes beaucoup moins souple que l’IT, mais où la transformation vers le lean a été une condition de survie. The phoenix project (3) illustre très bien les parallèles entre le monde industriel et l’agilité , plus proche de notre quotidien, la gestion des maintenances des TGV est opérée par la SNCF via des tableaux agiles où l’ensemble des bonnes pratiques sont respectées.

Se transformer pour survivre

Les architectes n’auront bientôt plus le choix, les projets planifiés à plusieurs années induisent trop de risques :

tant sur le budget (il est de plus en plus difficile d’obtenir un budget pluriannuel pour un projet qui délivrera dans un futur éloigné)
que sur l’adoption utilisateur : la solution prévue ne correspondra plus aux priorités du business lorsqu’elle aboutira.

L’architecte doit donc à la fois porter une vision à long terme permettant de respecter les règles de l’entreprise, garantissant l’exploitabilité de l’application et être capable de faire opérer des changements d’architecture pour répondre aux priorités métier à court terme.

Un changement de paradigme est nécessaire pour passer d’une organisation ou les technologies sont des capacités de soutien qui fournissent des services, des plates-formes ou des outils spécifiques au reste de l’organisation, tels que définis par les priorités, les ressources et le budget, à une organisation ou les technologies sont parfaitement intégrées et au cœur de tous les aspects de l’organisation en tant que moyen de libérer de la valeur et de permettre des réactions rapides aux besoins des entreprises et des parties prenantes (4).

Il nous faut nous habituer à la distribution de valeur dès le début du projet et nous préparer à prendre en compte les nouveaux besoins à chaque nouveaux sprints.

Les utilisateurs doivent se sentir impliqués, considérés. Leurs remarques doivent être valorisées afin de rentrer dans un cercle vertueux qui permettra de délivrer de l’expérience utilisateur de qualité en continu.

Le succès des projets dépend maintenant de la capacité des architectes à prendre en compte les besoins des utilisateurs, afin de toujours pouvoir s’adapter aux priorités métier et délivrer de la valeur au plus près des enjeux business. Ces changements bousculent certainement les habitudes ancrées dans la DSI, mais la valeur dispensée aux utilisateurs justifiera l’investissement à apporter dans ces changements.

1 The Psychology of Leadership: New Perspectives and Research edited by David M. Messick, Roderick M. Kramer
2 par exemple https://www.cloudockit.com/ ou https://www.hyperglance.com/
3 https://g.co/kgs/CDbqAY
4 https://www.mckinsey.com/business-functions/organization/our-insights/the-five-trademarks-of-agile-organizations