Modernisation applicative : Votre projet de plateforme est-il voué à l'échec ?

Dans un récent article de notre nouvelle rubrique « The Modernization Imperative (TMI) », Richard Seroter mettait en évidence l’avantage du « shifting down rather than shifting left » (déplacement vers le bas plutôt que vers la gauche). Cette méthode vise à tirer au maximum parti des fonctionnalités embarquées dans les plateformes utilisées afin d’alléger la charge de travail des développeurs et des opérateurs. En tant que conseiller auprès des responsables ingénierie des projets de modernisation dans le cloud, je partage pleinement son point de vue. Toutefois, si votre organisation compte construire sa propre plateforme (et par extension l’équipe IT qui va avec), rendez-vous service en vous posant quelques questions clés avant même de démarrer.

Créer ses propres plateformes technologiques en interne semble être devenu une pratique très en vogue dans les entreprises ces derniers temps. Et pour cause : elles permettent aux équipes IT d'être plus productives et plus autonomes, tout en centralisant la gouvernance et la gestion de la sécurité. Non seulement, le cloud est lui-même une plateforme (d’où le nom GCP, Google Cloud Platform) mais c’est aussi l’opportunité idéale d’y développer et déployer une multitude de plateformes complémentaires, qu’il s’agisse de plateformes de données avec BigQuery, de plateformes ML/AI avec Vertex AI, de plateformes de gestion d’APIs avec Apigee, ou encore de plateformes multi-tenant d’exécution de conteneurs avec Google Kubernetes Engine. Dit autrement dit, on assiste aujourd’hui à un phénomène de superposition et d’imbrications de plateformes ! 

Pour un DSI ou un architecte d'entreprise, investir dans le déploiement d’une plateforme présente des avantages évidents. Mais il y a un hic : personne d'autre dans l’entreprise ne s'intéresse à votre plateforme. Car ce n’est pas parce que vous avez déployé une belle plateforme prête à l’emploi que les utilisateurs vont nécessairement se jeter dessus.

Vous pouvez bien sûr forcer les gens à utiliser votre plateforme. Mais vous n’aurez alors atteint votre objectif qu’à moitié : tandis que vous avancez en centralisant votre gouvernance et en optimisant votre posture de sécurité, vos utilisateurs reculent car vous les obligez à apprendre, à s’équiper et à adopter une solution qu’ils n’ont pas demandée et dont ils n’ont (subjectivement) pas besoin. Une plateforme qu’ils détesteront par défaut, avant même de commencer à l’utiliser. Si leur expérience n'est pas parfaite (et la perfection n’est pas de ce monde), ils rejetteront la faute sur la plateforme et sur vous.

Alors quels sont vos moyens pour encourager l’adoption, voire l’adoption massive de votre solution ? L’implémentation de nouvelles plateformes internes est-elle systématiquement vouée à l’échec ? Fort heureusement, non !

De fait, afin de maximiser vos chances de succès, vous devrez avant tout développement vous poser ces trois questions essentielles : Pour qui construisez-vous la plateforme ? Qui va la construire ? Et enfin, comment allez-vous en mesurer le succès ?

Question 1 : Pour qui construisez-vous ?

« Commencez par l'utilisateur et travaillez en sens inverse ». Ce conseil, nous l’avons tous entendu. Mais, dans les grandes entreprises, il n’est pas toujours évident à suivre. En pratique, l’utilisateur réel de l’infrastructure est souvent un collaborateur d’un autre service dont les besoins sont exprimés par son chef de service ou le chef produit. Ces derniers interagissent ensuite avec le « responsable de l’infrastructure X » qui privilégie les fonctionnalités de backlog et délègue le design d’architecture à un architecte d’entreprise qui, à son tour, conseille les ingénieurs sur la conception de l’infrastructure. Vous l’aurez compris, à ce stade, plus personne ne se souvent des besoins réels de l’utilisateur !

Pour éviter d’en arriver là, voilà comment vous auriez dû aborder le problème : les ingénieurs qui mettent en œuvre l’infrastructure doivent régulièrement rencontrer l'utilisateur final en face à face, ce dernier étant accompagné par le chef produit de son service. Toutes les personnes impliquées dans la création ou l’exploitation de l’infrastructure doivent tenir dans une seule pièce - ou au moins tenir sur un seul écran "Meet/Zoom/Teams". C’est d’ailleurs la raison pour laquelle la meilleure des plateformes est souvent celle que les gens se sont auto-créée : vous pouvez difficilement être plus proche de l’utilisateur quand l’utilisateur, c’est vous.

Si avoir toutes les parties prenantes dans la même pièce est impossible, vous pouvez aussi vous appuyer sur un outil puissant : les « user watch parties » ou séances d’observation des utilisateurs. Le principe est simple : réunis dans une pièce, les ingénieurs observent l’utilisateur pendant qu'il interagit avec la plateforme dans la pièce voisine à travers un miroir sans tain.  

En réalité, il suffit d’enregistrer tout ce qui se passe sur leur écran et leurs remarques, en ayant bien entendu demandé leur accord au préalable. Recrutez cinq utilisateurs qui veulent bien se prêter à l’expérience et donnez-leur deux ou trois objectifs identiques à atteindre en utilisant l'ancienne plateforme que vous souhaitez remplacer ou la version MVP (Minimum Viable Product, ou Produit Minimum Viable) de celle que vous envisagez de construire. Demandez-leur de réfléchir à haute voix et d'exprimer toutes les suppositions qu'ils font et toutes les difficultés qu'ils peuvent éprouver.

Vous serez alors surpris de constater que même l'utilisateur le plus intelligent et le plus avisé prendra plus de temps que vous ne le pensiez et se retrouvera bloqué à des endroits auxquels vous n’auriez jamais pensé. Vous pourriez être tenté de rejeter ces réactions « anecdotiques » en les qualifiant d'aberrantes. Vous pourriez également imaginer qu'une documentation plus claire et une formation supplémentaire pourraient faire disparaître ces réactions. Mais la réalité est toute autre : vous assistez au véritable défi à relever par votre nouvelle plateforme : elle doit plaire à vos utilisateurs et rendre leur travail plus facile.

Les « user watch parties » présentent également l'avantage d'aligner toute votre équipe d'ingénieurs sur les mêmes priorités, pour la simple raison qu’ils viennent de partager les mêmes observations. Alors qu’avant la « user watch party » chaque membre de l’équipe pouvait avoir sa propre prochaine fonctionnalité favorite à construire, une fois la réunion terminée, il deviendra douloureusement évident que c’est bien une fonctionnalité existante qui méritera en priorité toute l’attention de l’équipe.

Question 2 : Qui va la construire ?

Avoir des idées, c’est facile. Les concrétiser, c’est plus difficile. Si vous n’abordez pas la question de manière critique, l’équipe qui construira la plateforme sera celle qui en a eu l’idée.
La pilule pourra parfois paraître difficile à avaler, mais n’oublions pas que l’enjeu ne tourne pas autour de vous, de vos ingénieurs en charge de la plateforme, du « Head of Platforms » (responsable des Plateformes) ou même du DSI : l’enjeu est centré sur l’utilisateur. Vous devez donc former une équipe infrastructure capable de satisfaire les besoins des utilisateurs en premier lieu, et vos ambitions personnelles ensuite.

Se pose alors la question de l’équipe idéale. Pour faire court, l’équipe plateforme idéale est dédiée au projet, petite et polyvalente. Il vaut mieux n’avoir que trois ingénieurs qui se consacrent exclusivement à la plateforme plutôt que 10 qui ont d’autres priorités et consacrent leur peu de temps libre au projet. Et oui, cette équipe suppose des effectifs dédiés et un sponsor exécutif fort, de sorte à encourager ses membres dès les premières phases de développement. C’est la manière dont toutes les entreprises « digital native » fonctionnent pour construire leurs plateformes et vous devez vous en inspirer.

La création d'une plateforme est un défi d'apprentissage, pas un défi d'exécution : les retours d'information rapides et l'apprentissage partagé sont essentiels à la réussite de l'équipe. Physiquement ou virtuellement, les membres de l’équipe doivent pouvoir travailler dans la plus grande proximité et dépendre au minimum d’autres équipes. Cette proximité est également essentielle pour éviter de tomber dans le piège du « ce n’est pas mon travail », chaque membre n’acceptant alors que les tâches qui relèvent de son expertise ou de la mission rattachée à son poste.  En adoptant un état d’esprit du type « montre-moi comment on fait », l’équipe confie naturellement la tâche à l’expert mais s’attend aussi à ce que tous ses membres soient capables de relever n'importe quel défi technique.

Enfin, il n’est pas impossible que vous ayez besoin de l’autorisation du RSSI, de l’architecte d’entreprise, etc., avant de pouvoir utiliser certains services. N’hésitez pas à intégrer ces personnes (ou un de leur représentant) dans l’équipe en lui accordant un rôle essentiel, au moins jusqu’à ce que leur contribution soit intégrée au projet sous forme de règle codée (Policy as Code) ou de schémas (blueprints) d’architecture. 

Question 3 : Comment mesurer le succès ?

Rien ne sert de respecter les délais et le budget impartis si c’est pour aboutir à une plateforme que personne n’utilise. Pour éviter un tel écueil, ne mesurez pas les réussites de votre équipe en fonction d’indicateurs de performance projet (Project KPIs). Optez plutôt en faveur d’indicateurs produits (Product KPIs) qui mesurent son utilité, le taux d’adoption ou encore la satisfaction des utilisateurs.

Il n’existe pas réellement de méthode universelle pour mesurer le succès d'un logiciel mais en obtenant des réponses à ces questions, vous pourrez quantifier sa réussite :

1. Combien de temps faut-il à l'utilisateur pour atteindre son objectif ? (moins = mieux)

2. Combien d'utilisateurs utilisent la plateforme et à quelle fréquence ? (plus = mieux)

3. Quels sont le degré de satisfaction des utilisateurs et la probabilité qu'ils recommandent la plateforme à d'autres employés ?

Chez Google, nous aimons utiliser le framework H.E.A.R.T.  pour évaluer l’expérience utilisateur d’un grand nombre de nos produits grand public. Nous utilisons également un framework modifié que nous avons baptisé S.U.P.E.R. pour certaines de nos infrastructures informatiques internes :

Partez à la rencontre de vos utilisateurs

Nous sommes convaincus que la proximité avec les utilisateurs est primordiale lors de la construction d’une infrastructure. Et nous avons expliqué plus haut comment retrouver une partie de cette proximité perdue en organisant des « user watch parties ». Nous avons également souligné l’importance des équipes polyvalentes et indiqué comment les inciter à construire une plateforme pertinente qui facilite réellement le travail des utilisateurs, plutôt que de se contenter de finaliser un projet informatique avant de passer au suivant. 

Bien entendu, nous avons ici à peine effleuré l’étendue de ce que signifie planifier, réaliser et gérer avec succès une plateforme pertinente en tant que produit.  Il y aurait encore beaucoup à dire sur l'importance des profils d'utilisateurs, la cartographie du parcours de l'utilisateur et le véritable rôle du chef produit, pour ne citer que ces quelques points.

De fait, si vous ne devez retenir qu’une seule chose de cet article, gardez à l’esprit que vous ne savez pas ce dont vos utilisateurs ont besoin et ce qu'ils veulent. Vous n'avez que des hypothèses, que vous devez vérifier. Et ce n'est pas parce que vous construisez la « bonne » plateforme qu'ils l’adopteront forcément. Vous devez impérativement aller à leur rencontre.