Comment mener un pilote avant de généraliser ?

Déployer un outil interne auprès de tout le monde le même jour expose à un risque simple : si quelque chose ne va pas, tout le monde est bloqué en même temps. Le pilote, parfois appelé phase d'essai, consiste à faire fonctionner l'outil en conditions réelles sur un périmètre restreint avant de l'étendre.

Pilote, démonstration et test : ne pas confondre

• Une démonstration montre l'outil sur des données d'exemple. Elle ne prouve rien sur l'usage réel.
• Les tests de recette vérifient que chaque fonction livrée correspond à la demande, souvent hors production.
• Un pilote engage du vrai travail : de vrais dossiers, de vrais clients, de vraies conséquences si cela se passe mal.

C'est cette dernière condition qui fait sa valeur. Les problèmes découverts en pilote ne se seraient jamais manifestés autrement.

Choisir le périmètre d'essai

Le groupe doit être volontaire, mais représentatif. Un groupe composé uniquement de personnes à l'aise avec l'informatique donnera un résultat trompeur.

Fixer à l'avance la durée et les critères

Un pilote sans fin devient un état permanent, avec deux façons de travailler qui coexistent. Écrivez avant de commencer :

1. La durée, assez longue pour couvrir un cycle complet de l'activité, y compris une clôture mensuelle si elle existe.
2. Ce que vous observerez : blocages rencontrés, dossiers traités jusqu'au bout, temps de prise en main, anomalies signalées.
3. Les conditions de généralisation : ce qui doit être vrai pour étendre l'outil.
4. La solution de repli : comment revenir à la méthode précédente si un problème grave survient, et sans perdre les données saisies.
5. Qui décide à la fin.

Pendant le pilote

• Ouvrez un canal simple pour signaler les problèmes, et répondez vite, même pour dire qu'une correction attendra.
• Passez voir les utilisateurs plutôt que d'attendre leurs messages : beaucoup de gênes ne sont jamais signalées.
• Distinguez l'anomalie, qui empêche de travailler, de l'inconfort lié à l'habitude, qui s'estompe.
• Corrigez rapidement ce qui bloque, mais évitez d'ajouter des fonctions en cours de route : le pilote teste une version, pas une cible mouvante.
• Notez tout ce qui devra être préparé avant la généralisation : formation, comptes, reprise de données.

Décider à la fin

Trois issues sont légitimes, et l'absence de décision n'en fait pas partie :

• Généraliser, en appliquant ce que le pilote a appris sur la formation et l'accompagnement.
• Corriger puis recommencer un essai court, si les problèmes sont identifiés et solubles.
• Renoncer ou revoir le besoin, si l'outil ne répond pas au problème. Cette décision, prise tôt, coûte bien moins cher que sa version tardive.

Cette logique de première version restreinte rejoint celle décrite dans l'article sur le produit minimum viable, appliquée ici au déploiement plutôt qu'à la conception.

Préparer la généralisation

Le passage à l'ensemble des utilisateurs se prépare pendant le pilote : comptes et droits à créer, documentation à finaliser, référents à former dans chaque service, données restantes à reprendre. Les utilisateurs du pilote deviennent souvent les meilleurs appuis pour accompagner leurs collègues, parce qu'ils connaissent les difficultés du début.

NexSecure met ses applications en service par étapes, dans le cadre de son offre de développement web sur mesure.