Un pilote qui ne fonctionne que dans son coin ne prouve rien

Le piège tel qu'il se présente

Une équipe démarre un pilote. Une cinquantaine de... non, une poignée de collaborateurs, un processus délimité, un outil rapide à activer. Après quelques semaines, les résultats au sein de ce petit groupe sont bons. On gagne du temps, le travail avance plus vite, les premières réactions sont positives. Le pilote est partagé en interne comme preuve que l'IA fonctionne pour l'organisation.

Ensuite, il se produit quelque chose de frappant : rien. Le pilote reste dans cette seule équipe, dans ce seul processus, avec ces cinq personnes. Les autres services observent, disent que c'est intéressant, et poursuivent leur travail comme ils l'ont toujours fait. Un an plus tard, le pilote existe toujours, mais l'organisation n'a pas changé.

Pourquoi cela semble logique

Le raisonnement derrière un pilote dans un coin n'est pas déraisonnable. On veut limiter le risque, on veut apprendre avant de déployer à grande échelle, on ne veut pas immédiatement bouleverser toute l'organisation pour quelque chose qui n'est pas encore prouvé. Commencer petit est un point de départ raisonnable.

Le problème ne réside pas dans le fait de commencer petit. Il réside dans ce qui ne se passe pas ensuite. Un pilote qui fonctionne bien dans un environnement protégé en dit surtout long sur cet environnement : des personnes motivées, un processus clair, peu de dépendances avec d'autres services. Il ne dit rien sur la capacité du reste de l'organisation à faire de même. Les données sont organisées différemment ailleurs, les processus se déroulent autrement, les personnes ont d'autres priorités. Le pilote prouve que cela peut fonctionner dans des conditions idéales, pas que l'organisation est prête à le faire fonctionner partout.

Une situation également reconnaissable est celle où deux enthousiastes et personne d'autre portent le pilote. Tant que ces deux personnes consacrent de l'énergie au projet, celui-ci avance. Au moment où l'une d'elles change de rôle ou est surchargée, le pilote s'arrête. Personne ne le remarque immédiatement, car l'organisation n'en avait jamais vraiment dépendu.

Comment reconnaître que vous y êtes

Il existe quelques signaux reconnaissables. Le pilote est mentionné dans les présentations internes comme une réussite, mais personne ne peut dire quelle est la prochaine étape pour l'élargir. Il n'existe aucun accord concret sur le moment où l'expérience se transforme en quelque chose de structurel, et donc il n'y a pas d'accord sur ce qui doit réellement en résulter de l'essai. Réussit-il si le gain de temps est démontrable ? Si la qualité reste constante ? Si d'autres équipes demandent elles-mêmes d'y avoir accès ? Sans ce critère, un pilote continue de tourner sans jamais aboutir nulle part.

Un autre signal est que la technologie fonctionne, mais que la manière de travailler autour de celle-ci n'a pas été adaptée. Les personnes utilisent l'outil en parallèle de leur processus existant plutôt qu'à sa place. C'est le signe que la technologie a pris de l'avance sur la structure dans laquelle elle doit fonctionner : l'organisation n'a rien changé pour faire de la place au nouveau travail, donc le nouveau travail s'adapte à l'ancien, et non l'inverse.

Un troisième signal est que personne en dehors du pilote ne se sent propriétaire du projet. Il y a une équipe qui l'expérimente, mais aucun manager, membre de la direction ou responsable de processus ne porte la responsabilité de la mise à l'échelle. Lorsqu'un pilote reste une démonstration plutôt qu'une propriété, c'est exactement le schéma dans lequel une démonstration sans propriétaire perd son effet dès que la nouveauté initiale s'estompe.

Et enfin : si vous imaginez ce qui se passerait si le pilote devait demain s'étendre à trois autres services, et que la réponse est floue ou inconfortable, alors vous êtes probablement déjà dans ce piège. Non pas parce que le pilote a échoué, mais parce qu'il n'a jamais été destiné à aller quelque part.

Le lien avec la maturité

La raison pour laquelle les pilotes restent bloqués dans leur coin tient rarement à la technologie elle-même. Elle tient à ce qui se trouve sous le pilote : le degré de maturité de l'organisation, de l'infrastructure informatique et de la gestion des données par rapport à ce qu'exige la mise à l'échelle. Un pilote peut fonctionner parfaitement sur un jeu de données isolé avec une équipe restreinte, et pourtant s'avérer impossible dès qu'il touche le reste de l'organisation, simplement parce que les couches fondamentales n'y sont pas adaptées. C'est aussi précisément pourquoi la mise à l'échelle sans que les bases soient en place échoue si souvent : le pilote n'a jamais été le problème, le terrain sous-jacent, si.

La mesure de maturité de hybridresourcing met ce terrain en lumière : cinq niveaux, du baseline à l'intelligence, sur sept dimensions qui déterminent ensemble si une organisation peut porter un pilote au-delà de son coin. Lors d'une session plot, plusieurs personnes répondent séparément, et l'écart entre leurs réponses révèle souvent déjà où l'organisation est en désaccord avec elle-même avant même qu'un mot sur la technologie n'ait été prononcé. Qui veut savoir à quoi un CEO devrait être attentif en matière de maturité IA avant le démarrage du prochain pilote y trouvera une piste.

Le pont vers la question suivante

Cette mesure porte sur la question de savoir si l'organisation peut porter un pilote : la structure est-elle prête, les données sont-elles en ordre, l'infrastructure est-elle suffisante. C'est une question différente de celle de savoir quelle part du travail lui-même est adaptée pour être confiée à l'IA. C'est à cette question que répond le scan de travail de FTE TO AI : il calcule, par tâche, quelle part du travail peut être reprise, indépendamment du fait que l'organisation dans son ensemble y soit déjà prête. Qui envisage d'élargir un pilote fait bien de se poser ces deux questions séparément avant de les confondre.