- Un rapport de VentureBeat AI indique que 87% des projets Data Science ne vont pas en production ;
- Gartner estimait en 2019 que 80% des projets d’IA de 2020 allaient rester à l’état de POC, menés par des “sorciers” dont les talents ne sont pas compatibles avec un passage à l’échelle de l’organisation ;
- Ce même rapport Gartner estime que seulement 20% des insights d’analytics vont réellement délivrer de la valeur en 2022.
Pendant la réalisation de PoCs en Data, se pose régulièrement la question : “stop ou encore ?”. Ou autrement dit : “Dois-je continuer à passer du temps à analyser ces données / améliorer ce modèle de Machine Learning / croiser ces différentes sources / benchmarker cette plateforme pour être sûr de mon choix, ou bien dois-je m’arrêter là et penser industrialisation ?”.
Notre conviction est qu’une brique Data n’a que très peu de valeur en soi, c’est son utilisation dans un Produit en production et en réponse à une problématique métier précise qui est importante. Et pour cela, rien de mieux que de passer rapidement à la création d’un MVP (Minimum Viable Product) fonctionnel de bout en bout.
La question à vous poser : Avez-vous souvent du mal à savoir s’il faut continuer d’investir du temps dans un PoC ou bien s’il faut s’arrêter et envisager l’industrialisation ?
Citons quatre raisons pour lesquelles il ne faut pas attendre trop longtemps avant de penser à la création d’un MVP.
Raison #1 : Éviter de se rendre compte in fine que le travail réalisé n’est pas exploitable en production
Plusieurs raisons peuvent amener à cette conclusion : un temps de latence trop élevé, une taille de modèle trop grande, une implémentation qui n’est pas adaptée pour le temps réel ou qui n’est pas compatible avec les contraintes techniques des environnements de production, etc.
Raison #2 : Un Produit Data est constitué de multiples briques logicielles
Ce que vous allez tester dans un PoC ne représente souvent qu’un tout petit morceau de l’ensemble de la chaîne de traitement nécessaire pour implémenter un Produit Data de bout en bout.
Il est nécessaire de voir un Produit Data comme un ensemble, et pas uniquement sous le spectre d’une seule brique précise (ne se concentrer que sur un modèle de Machine Learning par exemple). Passer rapidement à la création d’un MVP permet de se rendre compte au plus tôt de la difficulté potentielle de créer une chaîne de traitement complète, de l’ingestion de données à l’activation des résultats par un utilisateur final.
Raison #3 : Lever les principales incertitudes
Dans la majorité des cas, votre objectif dans une phase initiale d’un projet Data ne doit pas être de savoir quelle performance maximale vous pouvez atteindre, mais plutôt de lever vos principales incertitudes : “La donnée est-elle de qualité ?”, “Pouvons-nous croiser les différentes sources ?”, “Est-il techniquement possible de faire ce type de prédiction ?”, “Quel niveau de performance pouvons-nous atteindre sans effort ?”, “Voyons-nous un fort potentiel d’amélioration de ces performances ?”
Vous l’aurez compris, il n’y a pas forcément besoin de plusieurs mois d’investigation pour répondre à ces questions.
Raison #4 : Faire simple ne veut pas dire faire moins performant
De nombreuses approches et solutions permettent d’avoir dès le départ des performances tout à fait intéressantes. L’utilisation de services managés ou bien de briques logicielles déjà implémentées sur d’autres projets en sont des exemples.
Notre recommendation : Être convaincu que la valeur d’un Produit Data réside dans sa capacité à répondre à une problématique business précise et exploitable en production.
Votre North Star pour un Produit Data doit être la mesure de son impact business.
Il est donc essentiel d’être au clair sur la problématique à résoudre. Dans ce cas de figure, le fait de vous lancer rapidement dans la réalisation d’un MVP est un moyen très efficace de vous assurer que vous apportez réellement de la valeur à ce problème. Et parfois, ou devrait-on dire souvent, lorsque l’on a passé un temps conséquent à réellement comprendre la problématique de ses utilisateurs, une visualisation de données claire ou bien quelques règles métier bien pensées pourront apporter une valeur incroyable.
Avoir rapidement un MVP avec une chaîne de traitement de bout en bout en production permet de se poser les bonnes questions et de considérer les bonnespriorités pour la suite. Est-ce vraiment sur l’amélioration des performances de votre modèle que vous devez concentrer toute votre énergie ? La boucle de feedback mise en place ne met-elle pas en évidence d’autres zones permettant de faire un plus grand gain en apport de valeur (focus sur la qualité de la donnée, incorporation de nouvelles sources de données, retravail de la mise à disposition des résultats, etc.) ?
Ne concluez pas de ces constats qu’il faut éviter de faire des PoCs. Il existe d’ailleurs selon nous deux principaux cas de figure pour lesquels le fait de ne pas aller en production est en réalité une bonne nouvelle :
Lorsque le PoC en question est en fait une étude
Cette étude a pour but de répondre à une question précise par la donnée et de générer des enseignements à partir de celle-ci. Il n’est pas question ici de Produit, mais bien d’une analyse exploratoire. Toute la difficulté pour ne pas retomber dans l’écueil de l’exploration infinie est alors d’avoir une question précise à laquelle répondre.
Lorsque le PoC a démontré que le projet n’apporte pas de valeur en l’état
Il n’est pas rare qu’en effet, un PoC permette de conclure qu’en l’état, il ne vaut pas la peine d’investir du temps et de l’argent dans la création d’un produit industrialisé. Est-ce un échec ? Aucunement, si vous avez bien structuré votre PoC et qu’il vous permet d’en tirer des enseignements concrets. Le PoC aura alors rempli entièrement son rôle : vous permettre de prendre une décision.
Après cette phase de PoC bien cadrée, le projet peut :
- Passer en phase MVP (Minimum Viable Product) ;
- Être mis en standby (par exemple faute de données, ressources disponibles ou changement de priorité) ;
- S’arrêter.
Les causes d’un arrêt peuvent être nombreuses : des validations des hypothèses non concluantes, un manque de données ou d’historique nécessaire, un apport minime par rapport à l’investissement, un outil du marché existant à moindre coût qui répond à la problématique, etc.
Nous sommes conditionnés par la crainte de l’échec, et tentons parfois de poursuivre des projets coûte que coûte bien que le gain potentiel soit très marginal, voire inexistant. Or, répondre “non” à la question “faut-il investir sur ce sujet ?” n’est pas un échec. C’est un enseignement à condition que ce “non” soit accompagné d’explications qui, elles, apportent une réelle valeur. La décision de l’abandon d’un PoC fait partie du processus de Discovery en Data.
C’est cette discipline de “fail fast” qui au final compte le plus, afin de tirer des enseignements au plus tôt et pivoter et garantir les succès futurs.
Retrouvez l’ensemble des écueils limitant l’impact de la Data sur les produits et organisations dans notre eBook dédié.
