Alors que vous vous rapprochez de la fin des cycles de votre projet, le déploiement est une phase des plus intéressantes. C’est durant cette étape que vous aurez un grand nombre de commentaires de tous genres; y compris de la part de votre équipe de projet dont certains membres finiront par réaliser l’ampleur des changements.
Bien qu’il n’y ait pas de règles tellement les technologies, les contextes et les besoins différents, l’idée de s’appuyer sur une base de testeurs est souvent assez futé. Il va de soi que durant toute la gestation de votre projet, vous êtes resté en contact avec la réalité de vos utilisateurs (email de status sur la progression hebdomadaire, comité de pilotage, …). On pourrait donc croire que si tout a été validé par ces personnes là, il nous suffit d’appuyer sur quelques boutons, d’attendre quelques heures le temps que le contenu se réplique sur les différents serveurs, que le cache se mette à jour et hop ! Et bien dans le fond pourquoi pas, oui, mais imaginons juste une seconde que votre intranet n’ait pas pris en compte les besoins d’une filiale basée sur un autre site, ou que la police que vous utilisez ne soit pas disponible pour les standards ISO de la république Tchèque ou de la Chine, imaginons enfin qu’il y ait tout simplement une fonctionnalité qui ne marche pas dans l’environnement de production.
C’est pour toutes ces raisons et quelques unes de plus qu’on fera notre possible pour lancer notre déploiement en phases. On ne peut pas toujours saucissonner par géographie mais pourquoi pas lancer les scripts en premier puis ensuite le front-end; le web mobile en premier puis le www; etc…
Cette approche en phase est très commune dans de nombreux domaine. Facebook proposait récemment de choisir entre ses deux design, ce qui n’est même pas une migration déguisée mais bien un simple « habituez-vous tout de suite parce que dans X jours vous n’aurez plus le choix ». Nokia met à jour les firmware de ses séries N par vague de codes produit s’assurant ainsi que les mises à jour n’ont pas d’effet secondaire indésirable. Le portail Vodafone live est en version 1.0 ou 2.0 en fonction du forfait, du type de téléphone et qui sait quoi d’autre encore.
Dans la gestion de projet moderne ou agile, on va privilegier les developements à cycles courts. Cela implique plus de « releases », à un rythme plus soutenu mais forcement basées sur moins de tests. En particulier, l’une des phases que l’on va externaliser est le User Acceptance Testing (UAT). Dans le vieux monde, cette phase représente la période durant laquelle de vrais utilisateurs vont tester le résultat de votre projet et dire si oui ou non le produit est bon pour la mise en ligne. Lorsqu’un Nokia Labs met en ligne une application sur son portail, bien évidemment, il y a eu une version allegée de UAT mais le vrai examen va être conduit par les utilisateurs eux meme, les early-adopters.
Un early-adopter est donc un utilisateur qui va tester religieusement une technologie / un produit. Après de nombreuses heures d’examen, le early-adopter va proposer une liste d’améliorations pour les futures mises à jour ainsi que des conseils de tous ordres (business, technologique, design, écologique) afin que le produit réponde aux mieux aux besoins ultra-exigeants des technophiles.
Si vous voulez en savoir plus sur les early adopters, je vous conseille le très bon article de Tzer2 qui se pose la question suivante: Pourquoi tant de gens achètent les gadgets le jour de leur sortie ?
Dernier point, ne pas confondre Beta-testers et Early-adopters: leur profil et leur utilisation du produit les séparent. Si un beta-testeur vous donnera d’excellents retours (notamment sur l’execution), l’early-adopter va réellement chercher à intégrer le produit dans ses outils du quotidien.
Une fois tous les retours compilés et repertoriés dans le triangle de la qualité, il ne vous restera qu’à passer aux itérations suivantes et étapes après étapes finir votre déploiement avec le sourire !
Grégory Raby
