Du lab aux opérations : le transfert que personne ne prépare

La plupart des pilotes ne meurent pas dans le lab. Ils meurent dans les trois mois qui suivent, quand ceux qui les ont construits prennent du recul et que ceux qui doivent les faire tourner n'ont jamais vraiment été consultés. Un bon transfert commence dès le premier jour du pilote, désigne un seul repreneur côté opérations et transfère quatre choses : la décision, la ligne budgétaire, le savoir-faire et les indicateurs. S'il en manque une, le pilote retourne discrètement au lab ou disparaît.

Pourquoi le transfert est l'endroit où meurent les bons pilotes

Un lab est conçu pour être différent des opérations. Il va plus vite, tolère l'ambiguïté, emprunte des personnes et contourne les processus standard. C'est précisément ce qui lui permet de tester des idées nouvelles. C'est aussi pour cela que ce qu'il produit s'emboîte rarement dans la machine qui devra le faire tourner.

Vijay Govindarajan et Chris Trimble décrivent cette tension dans The Other Side of Innovation (2010) : le « moteur de performance » qui fait tourner l'activité d'aujourd'hui est conçu pour la répétabilité, et le travail d'innovation a besoin d'un partenariat avec lui plutôt que d'un mur entre les deux. Les labs qui traitent les opérations comme le public d'une démo finale, plutôt que comme un partenaire dès le départ, condamnent le transfert à l'échec.

Les symptômes habituels sont bien connus :

• Le pilote « a marché », mais personne côté opérations ne s'était accordé sur ce que « marcher » voulait dire.
• L'équipe du lab était la seule à comprendre comment il fonctionnait.
• Il y avait de l'argent pour le pilote, mais aucune ligne dans le budget de fonctionnement de l'année suivante.
• Le manager repreneur a hérité d'un nouveau service en plus de ses objectifs existants, sans que rien ne lui soit retiré.

Pas à pas : préparer le transfert dès le premier jour

1. Désigner le repreneur avant le démarrage du pilote

Avant de consacrer une semaine au pilote, trouvez la personne côté opérations qui en portera le résultat s'il réussit. Pas un sponsor qui aime l'idée ; le manager dont l'équipe le fera tourner un mardi ordinaire. Posez-lui la question sans détour : « Si cela marche, est-ce que vous le reprenez ? » Si la réponse est « peut-être », considérez-la comme un résultat en soi. Un pilote sans repreneur est un projet de recherche, et il doit être cadré et présenté comme tel.

2. Convenir du critère de réussite avec le repreneur, par écrit

Écrivez, avec le repreneur, quel résultat le ferait accepter la reprise. Limitez-vous à deux ou trois indicateurs qui comptent déjà pour lui : délai de traitement, taux d'erreur, coût par dossier, réclamations. Un arbre de KPI aide à relier l'indicateur du pilote aux objectifs sur lesquels le repreneur est évalué. Si le critère de réussite du lab et celui du repreneur divergent, c'est celui du repreneur qui l'emporte.

3. Intégrer une personne des opérations dans l'équipe du pilote

Une personne de l'équipe repreneuse doit travailler sur le pilote, au moins à temps partiel, dès le départ. Elle repère les règles, les systèmes et les habitudes que le lab manquerait autrement, et elle rapporte le savoir-faire chez elle. Cette seule décision fait plus pour le transfert que n'importe quel document.

4. Cartographier le futur service, pas seulement le pilote

Les pilotes tournent sur des solutions de contournement : un membre du lab qui répond aux e-mails à la main, un tableur à la place d'un système, un manager qui valide personnellement les exceptions. Avant la décision de passage à l'échelle, dessinez un service blueprint du service tel qu'il fonctionnera sans le lab : chaque étape en front-office, chaque étape en back-office, chaque système et chaque règle dont il dépend. Les écarts que vous trouvez constituent votre plan de travail pour le transfert.

5. Faire un premortem du transfert lui-même

Réunissez l'équipe du lab et l'équipe repreneuse et demandez : « Nous sommes six mois après le transfert et le service a été discrètement arrêté. Que s'est-il passé ? » Un premortem fait remonter les vrais risques : un contrat fournisseur qui arrive à échéance, une règle qui n'a jamais été modifiée, une équipe qui a perdu des postes. Attribuez chaque risque à quelqu'un.

6. Écrire la matrice RACI de la période de transition

Pour chaque activité du blueprint, décidez qui est responsable, qui rend des comptes, qui est consulté et qui est informé : pendant le pilote, pendant la transition et après. Une matrice RACI sur trois périodes rend visible le déplacement de la responsabilité. Le lab doit rendre des comptes sur un peu moins chaque mois.

7. Sécuriser la ligne budgétaire avant de fêter le succès

Un pilote financé sur le budget du lab n'a pas d'avenir tant que personne ne le fait basculer dans un budget de fonctionnement. Travaillez tôt avec la direction financière : combien coûtera-t-il à grande échelle, sur quelle ligne, à partir de quand ? Si le cycle budgétaire se clôt avant la fin du pilote, demandez une ligne provisoire fondée sur le critère de réussite.

8. Transférer avec une check-list et une date

Utilisez une check-list de déploiement qui couvre les personnes formées, les procédures rédigées, les systèmes paramétrés, les règles modifiées, le support organisé et les indicateurs en place. Fixez une date de transfert et annoncez-la avec un plan de communication avec les parties prenantes, pour que les équipes, les clients et la direction sachent qui porte désormais le service.

9. Rester disponible, puis se retirer

Convenez d'une période fixe, souvent un ou deux cycles du service, pendant laquelle le lab reste joignable pour répondre aux questions. Ensuite, le lab ne participe plus. Si le service ne peut pas tourner sans le lab, c'est qu'il n'a pas été transféré.

Ce qui est réellement transféré

Il est utile de nommer les quatre choses qui doivent changer de mains, car les labs n'en transfèrent souvent qu'une seule.

Vérifiez chaque ligne avant la date de transfert. Un pilote qui en a transféré trois sur quatre reste un pilote du lab.

Exemple illustratif

Illustratif. Le lab d'une autorité organisatrice des transports urbains a testé un nouveau processus de traitement des réclamations liées à l'accessibilité. Pendant le pilote, deux designers du lab triaient les réclamations à la main et rappelaient chaque plaignant sous 48 heures. La satisfaction a augmenté et le pilote a été déclaré réussi.

Quand le lab a présenté les résultats, la directrice du service client a demandé qui passerait les appels. Son équipe n'avait pas de budget pour cela et l'outil de gestion des réclamations ne permettait pas de signaler les cas d'accessibilité. Le pilote est resté bloqué cinq mois.

Le lab a redémarré avec la directrice comme repreneuse. Une conseillère expérimentée a rejoint l'équipe pendant six semaines. Ensemble, elles ont dessiné un blueprint qui remplaçait le tri manuel par une nouvelle catégorie dans le système existant, convenu d'un rappel sous 72 heures que l'équipe pouvait réellement tenir, et basculé le coût dans le budget du service pour l'année suivante. Le lab est resté disponible pendant un trimestre, puis s'est retiré. L'objectif de 72 heures était moins spectaculaire que le pilote. Lui, en revanche, a tenu.

À faire, à éviter

À faire

• Désigner le repreneur avant le démarrage du pilote.
• Laisser le repreneur définir la réussite avec ses propres indicateurs.
• Intégrer une personne des opérations dans l'équipe du pilote.
• Concevoir la version à grande échelle sans les contournements du lab.
• Fixer la date à partir de laquelle le lab ne participe plus.

À éviter

• Présenter aux opérations un pilote terminé comme une surprise.
• Remettre un jeu de slides et appeler cela un transfert.
• Mesurer la réussite uniquement avec des indicateurs du lab, comme le « nombre d'idées testées ».
• Ajouter un nouveau service à la charge d'une équipe sans rien lui retirer ; une liste des activités à arrêter aide ici.
• Garder le lab comme propriétaire permanent « juste pour l'instant ».

Les questions qu'on nous pose

Quand un lab doit-il transférer un pilote aux opérations ? Quand le critère de réussite du repreneur est atteint et que les quatre transferts (décision, budget, savoir-faire, indicateurs) peuvent tous être menés à bien. La préparation commence au début du pilote ; le transfert lui-même a lieu quand la version à grande échelle peut tourner sans les personnes du lab.

Qui doit porter une innovation après le pilote ? Le manager dont l'équipe la fera tourner au quotidien, ni le sponsor ni le lab. Si personne n'accepte de la reprendre, le pilote doit être arrêté ou repensé, ce qui est une issue légitime. Voir comment bien arrêter un projet.

Pourquoi des pilotes réussis ne passent-ils pas à l'échelle ? Le plus souvent parce que les pilotes tournent sur des contournements et une attention empruntée qui n'existent pas à grande échelle, et parce que personne n'a fait basculer le coût de fonctionnement dans un budget opérationnel. La solution : concevoir la version à grande échelle pendant le pilote, pas après.

Pour aller plus loin

Pour une vue d'ensemble, lisez qu'est-ce qu'un lab d'innovation, et pourquoi la plupart échouent et 5 raisons pour lesquelles les labs d'innovation ferment dès la deuxième année ; un lab qui ne transfère rien survit rarement à son deuxième budget. Les guides méthodologiques qui portent l'essentiel du transfert sont le service blueprint, la matrice RACI, le premortem et la check-list de déploiement.