Le scénario est connu. Le projet pilote fonctionne, la démo plaît à la direction, tout le monde convient que c'est prometteur… puis plus rien. Six mois plus tard, l'outil tourne encore dans son coin, et personne ne sait trop s'il faut l'arrêter ou le déployer.
Ce pilote n'a pas échoué. Il a réussi, mais personne n'avait décidé à l'avance ce que voulait dire « réussir », ni ce qui se passerait ensuite. C'est ma conviction : l'écart entre un projet pilote et un déploiement est rarement technique. C'est une série de décisions à prendre avant de commencer, pas après.
Ce qu'un pilote cache
Un projet pilote est conçu pour réussir, et c'est normal. Il fonctionne généralement dans des conditions favorables : un échantillon de données propre, quelques utilisateurs motivés (souvent ceux qui l'ont demandé), une installation à part et une équipe qui surveille tout de près et corrige au fur et à mesure.
Un pilote, c'est l'entraînement par beau temps; la production, c'est le jour de la course, sous la pluie. Elle enlève ces quatre béquilles. Les données sont incomplètes et changent sans arrêt. Les utilisateurs sont occupés et n'ont rien demandé. L'outil doit s'intégrer à l'ERP, au CRM ou à la messagerie où les gens travaillent déjà. Et après quelques semaines, plus personne ne surveille de près.
Avant le pilote : trois décisions
Les critères de réussite, et d'arrêt. Écrivez quel résultat justifierait de passer en production, et quel résultat justifierait d'arrêter. Les deux. Un pilote sans critère d'arrêt ne se termine jamais vraiment : il s'essouffle.
Le responsable, côté affaires. Si le pilote réussit, qui sera responsable de l'outil? Qui soutiendra les utilisateurs, surveillera la qualité, décidera des changements, paiera la facture l'an prochain? Sans cette personne, l'outil devient orphelin le jour où l'équipe projet passe à autre chose.
Le budget de production, au moins dans ses grandes lignes. Un pilote coûte peu, volontairement. La production coûte davantage : intégration, sécurité, soutien, licences à pleine échelle, formation. Si cet argent n'est pas prévu, un pilote réussi vous place dans une position délicate : l'organisation a dit oui à l'idée, mais pas à la facture.
Pendant le pilote : deux conditions
Travailler tôt avec les vraies données. Testez sur les données que vous utiliserez réellement, avec leurs trous et leurs incohérences. Un pilote qui ne fonctionne que sur un échantillon nettoyé vous apprend quelque chose sur l'échantillon, pas sur vos opérations.
Prévoir l'intégration dès le départ. Un outil qui vit dans une fenêtre à part est un outil qu'on oublie. Déterminez comment les résultats atteindront les systèmes et les écrans que les gens utilisent déjà, et qui construira ce lien.
Le cas de l'IA
Avec l'IA, deux exigences s'ajoutent.
La qualité bouge avec le temps : les données évoluent, les processus changent, le fournisseur met son modèle à jour. Décidez comment la qualité sera mesurée en production, à quelle fréquence et à partir de quel seuil on intervient.
Les erreurs doivent être repérées. Déterminez quels résultats une personne doit réviser avant qu'ils soient utilisés, et faites de cette révision une tâche assignée, pas une bonne intention. Là où une erreur coûte peu, on peut réviser moins; là où elle coûte cher, on révise davantage. Mais c'est une décision, pas un hasard.
La règle
Ne lancez pas un pilote si vous ne pouvez pas répondre à trois questions. S'il réussit, qui en sera responsable? Où va-t-il fonctionner? Combien coûtera la production, à peu près? Si une des réponses est « on verra », votre pilote est une démo avec un échéancier plus long.
Liste de contrôle : passer en production ou non
- Les critères de réussite fixés avant le pilote sont atteints, et documentés
- L'outil a été testé sur des données réelles, non filtrées
- L'intégration aux systèmes existants est conçue et budgétée
- Un responsable, côté affaires, accepte la responsabilité de l'outil en production
- Le soutien, la surveillance et les mises à jour sont assignés
- Le budget de production est approuvé
- Les utilisateurs hors du groupe pilote sont formés, ou un plan de formation existe
- Pour l'IA : indicateurs de qualité, règles de révision et seuil d'intervention définis
- Un retour en arrière est possible si la mise en production tourne mal
Votre pilote piétine déjà?
Il n'est pas trop tard pour appliquer la même logique. Écrivez maintenant les critères de réussite, comme si le pilote commençait aujourd'hui, et mesurez-le honnêtement par rapport à ces critères. Prenez ensuite l'une de trois décisions, avec une date :
- Déployer : nommer le responsable, approuver le budget de production et planifier l'intégration.
- Corriger : préciser ce qui doit changer, d'ici quand et quel résultat permettra de trancher.
- Arrêter : consigner ce qu'on a appris et fermer le projet en bonne et due forme.
Arrêter est une issue tout à fait légitime. Un pilote qui se termine par un « non » clair a fait son travail. Le seul résultat à éviter, c'est celui où personne ne décide.
En terminant
Un projet pilote est un bon outil quand il sert à répondre à une vraie question. C'en est un mauvais quand il sert à repousser une décision. Si vous avez un pilote qui piétine, ou un autre sur le point de démarrer, une courte conversation autour de ces questions permet généralement de voir rapidement dans quelle situation vous êtes.