Mobile et innovation en entreprise

Pour un premier jet ou un prototype : avantage aux équipes réduites

Passer d'une idée d'application à une première version relève moins de l'éxécution que de la discussion. Et s'accomode moins bien des workflows trop segmentés.

20160923-petite-equipe-prototype-2.jpg

Réaliser une première version d'une application n'est qu'un projet technique 

Prototype, première version, Proof of Concept (POC), v1... On entend et on utilise de plus en plus ces termes quand on parle de projet informatique, et c'est tant mieux : ils témoignent du choix de plus en plus fréquent de réaliser une première version pour pouvoir la confronter dès que possible aux utilisateurs auxquels elle est destinée, et réduire au maximum le risque de se tromper tout en permettant d'apprendre au contact du terrain.

Ces termes, souvent associés à du vocabulaire technique, renferment pourtant une grande part de questionnement, d'hypothèse, de réponses et de rédaction qui relève autant du porteur de projet non technique que de l'équipe qui réalisera le projet lui même. En effet, que le porteur du projet ait l'idée d'une application, d'un objet connecté, d'une interface web ou d'un outil de réalité augmentée, une bonne partie du travail consiste à préciser ce à quoi l'outil ressemblera, puis à le questionner à tous les points de vue (point de vue de l'utilisateur surtout, point de vue technique, ergonomie...). C'est vrai pour un simple site web, c'est tout aussi vrai pour la prochaine application que vous souhaitez développer pour systématiser le quotidien de vos commerciaux : c'est d'abord un travail marketing, puis un travail technique. L'enjeu étant effectivement que ceux qui réaliseront le projet soient les mêmes que ceux qui y ont réfléchi en amont, d'où l'intérêt des intervenants pluridisciplinaires qui travaillent en petite équipe. 

Le prototype : la substanfique moëlle de nombreuses expertises

La réalisation d'une première version de n'importe quel projet informatique implique le meilleur de nombreuses expertises, pour deux raisons. D'une part, car un prototype cherche à mimer une expérience réelle en se limitant au strict nécessaire. Il faut se restreindre en quantité, pas en qualité, pour que la première version témoigne de ce qui suivra. Les compétences requises pour bien travailler sont donc les mêmes que sur un projet d'amélioration ou de refonte : chef de projet, analyste marketing, UX designer, graphiste, architecte informatique, développeur back-end, développeur front-end, développeur spécialisé en cas de technologie plus spécifique... Du beau monde !

D'autre part, car protoype signifie nouveauté. Une fois cette idée rendue réelle,  une fois l'application réalisée, elle sera déployée et viendra modifier les usages de ceux qui l'utilisent. Que ce bouleversement soit profond ou superficiel, imposé ou voulu, il fait partie intégrante du concept de v1 : il faut le prendre en compte comme l'un des chantiers indispensable de cette v1. On sort alors de la technique, du design, du produit lui-même, et on recule pour appréhender l'environnement dans lequel cette nouvelle application va être déployé, comment elle sera accueillie par les futurs utilisateurs, comment la présenter sous son meilleur jour pour qu'elle soit utilisée et non pas rejetée. ; la gamification peut être un moyen d'y parvenir. Et aux compétences techniques et créatives déjà variées que requiert la réalisation d'un proto, on ajoute les compétences de marketing stratégique, marketing opérationnel, communication, moins évidentes mais tout aussi indispensables au succès de la nouvelle application.

Analytics : la raison d'être d'un Proto

Un des grands avantages de déployer rapidement une version simple d'un projet plus global est d'obtenir les retours du terrain. En questionnant les premiers utilisateurs sur ce qu'ils en pensent, déjà. Mais aussi en observant comment ils utilisent l'application ou l'objet connecté que vous avez imaginé. C'est précisément à ça que servent les analytics. Contrairement à ce que l'on croit souvent, tout projet digital ne génère pas nativement de données d'utilisation : il faut décider d'une stratégie analytics en fonction de ce que l'on souhaite savoir, puis l'intégrer techniquement pour configurer enfin le tableau de bord qui permettra de lire les observations ainsi permises pour comprendre l'utilisation. A ce titre, les analytics sont une brique absolument indispensable de tout prototype, qui par nature est amené à évoluer : les analytics fourniront les informations pour faire les bons choix, en toute connaissance de cause.

 

L'enjeu #1 pour réaliser un prototype ou une v1: une bonne communication

La première version d'une application peut s'imaginer comme le résultat d'un travail de pâte à modeler. D'un périmètre défini dans les grandes lignes, il faut accepter de réarranger le contenu. Le cadrage en amont est indispensable, pour ne pas que flexibilité soit synonyme de laisse-aller. Mais dans un contexte où il faut prendre en compte de très nombreux éléments (cf. paragraphe précédent) qui se précisent ou évoluent au fur et à mesure qu'on avance dans le projet, il faut pouvoir accepter d'intégrer dans sa feuille de route un élément qui n'était pas prévu, mais qui apparaît au cours du projet comme une évidence. Ce sont les premiers retours, d'où qu'ils viennent, qui façonnent la suite des travaux à réaliser. 

Dans le cas d'un projet informatique, ces points de vue pertinents qui influent sur le périmètre peuvent venir de tous les côtés. Quand l'objectif est de passer d'une idée à une première réalisation, les moyens importent peu, seul le résultat à atteindre compte (et le budget pour le réaliser, certes). Tous les choix effectués en amont (sur un design, sur l'utilisation d'une technologie...) risquent d'être remis en question, pour le bien du projet, parce que l'UX designer constate après les premiers échanges avec de vrais utilisateurs qu'ils ne peuvent pas utiliser l'application car ces utilisateurs sont des jardiniers qui ont sur aux mains des gants de jardinage, ou parce que le développeur front-end constate que le drag and drop qui semblait une si bonne idée n'est géré que sur certains navigateurs...

Ces remarques qui changent la physionomie du projet sont une chance. Elles permettent d'éviter le gâchis. Mais pour que ces points de vue soient pris en compte, il faut que deux conditions soient réunies. D'une part, la communication doit être facile, et impliquer toutes les parties prenantes au projet. D'autre part, il faut que chacune des parties soit en mesure de donner son avis, et de considérer qu'il pourrait être pris en compte. Ce qui est moins le cas dans une organisation structurée et hiérarchisée où une distinction nette entre conception et réalisation limite le rôle de nombreux intervenants (en particulier les développeurs) à de l'éxécution pure. Vive l'équipe élastique !

Combien coute une application ? Télécharger notre ebook

 

 

 

Droits photo (CC) : http://www.johnmh.com/advreadings/lionmouse.htm

 

Publié par Thomas Bompaire
Le 27 sept. 2016 11:06:00
Retrouvez moi ici :