Plus de 80% des projets data ne partent pas en production, et alors ?

Plus de 80% des projets data ne partent pas en production, et alors ?

De nombreux chiffres ont été publiés et font du bruit sur le taux de projets data qui échouent à aller en production et ne dépassent pas le stade du PoC (Proof of Concept) :

  • Un rapport de VentureBeat AI explique 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 une exploitation de la data Ă  l’échelle de l’entreprise
  • Ce mĂŞme rapport Gartner estime que seulement 20% des insights d’analytics vont rĂ©ellement dĂ©livrer de la valeur en 2022

Mais au final, est-ce une si mauvaise chose que certains projets n’aillent pas plus loin ? La question mérite d’être posée.

Ne pas aller en production n’est pas synonyme d’échec

Il existe selon nous deux principaux cas de figure pour lesquels le fait de ne pas aller en production est en réalité une bonne nouvelle.

Premier cas : Mon PoC est en réalité une analyse exploratoire one-shot

Le premier d’entre eux est lorsque le PoC en question est en fait une “étude”, qui 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 bien d’avoir une question précise à laquelle répondre. Une demande trop floue du type “voyons s’il y a de la valeur dans telle ou telle source de donnée que nous n’avons pas encore exploitée” ne permet pas de s’organiser efficacement.

Deuxième cas : Mon PoC a démontré que le projet n’apporte pas de valeur en l’état

Concernant ce deuxième cas de figure, il convient de revenir à la fameuse question à laquelle doit répondre un PoC : “mon niveau d’incertitude sur le potentiel business et la faisabilité technique du projet a-t-il été suffisamment baissée pour me permettre de prendre une décision concernant la création d’un produit de bout en bout ?”. Et il n’est pas rare qu’en effet, un PoC permette de conclure qu’en l’état, il ne vaut pas la même 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’elle vous permet d’en tirer des enseignements concrets. Le PoC aura rempli entièrement son rôle : vous permettre de prendre une décision.

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 voir inexistant. Hors, répondre “non” à la question “faut-il investir sur ce sujet” n’est pas un échec, c’est un enseignement, dans la mesure où ce non est accompagné d’explications qui, elles, apportent une réelle valeur. Ce “non” vient-il du fait que la qualité de la donnée n’est pas au rendez-vous ou bien que ce projet ne réponde pas à un réel besoin utilisateur ? En fonction de la réponse, vos prochaines étapes seront très différentes !

Il est de plus en plus fréquent que pendant les sprints, les équipes Data consacrent un peu de temps sur les sujets d’innovation et la validation rapides des hypothèses récoltées lors des échanges avec les interlocuteurs business. En quelques jours, maximum quelques semaines, les équipes évaluent la faisabilité et l’apport que le projet va avoir (il existe plusieurs canvas qui permettent d’évaluer la pertinence d’un projet, nous en reparlerons dans un prochain article).

Après cette phase, 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.

Il est donc important d’identifier les causes et d’arrêter le projet au plus tôt.

Les cas de figure où le fait que le PoC n’aille pas en production est bien un échec

Réfléchissons à quelques-unes des causes d’arrêt des projets data (et Data Science en particulier). Cette liste ne se prétend pas être exhaustive, mais permet de donner des grandes tendances (nous n’abordons par exemple pas ici les problématiques de Data Quality ou de Gouvernance).

Manque de cadrage et de vision produit en amont des Use Cases

Combien de projets data on été démarrés juste parce qu’il était possible de résoudre ce sujet par de la Data Science ? Beaucoup d’équipes data sont organisées de telle sorte qu’elles se mettent en position de “vendeurs” de projets auprès des métiers, tentant de les convaincre que ce projet de détection de fraude ou de segmentation client va les aider dans leur quotidien.

S’il y a bien une pratique à retenir du Product Management, c’est bien de créer des produits qui résolvent des problèmes identifiés des utilisateurs. Les Produits Data n’échappent pas à cette réalité. Si le Use Case ne résout pas un problème concret et identifié, alors il n’apportera pas de valeur business.

Le rôle de Product Manager appliqué à la data (ou Data Product Manager) est donc clé pour mettre en place une réelle méthode et discipline dans l’identification, le cadrage, le prototypage et le développement de produits data.

Un développement de Proof of Concept en mode tunnel de plusieurs mois

La Data Science a une composante de “recherche” indéniable que l’on ne peut pas éviter. C’est d’ailleurs tout l’objectif des PoCs en Data Science : faire de l’exploration et tester des hypothèses afin de tenter de résoudre le problème posé, pour ensuite prendre une décision sur la possibilité (et l’intérêt) à l’industrialiser.

Jusque-lĂ , tout va bien.

Les problèmes apparaissent lorsque ce mode de fonctionnement vire aux extrêmes : des PoCs qui n’en finissent jamais. En effet, il y aura toujours une nouvelle feature à tester dans un modèle, toujours une nouvelle source de données à incorporer, toujours des paramètres à tuner, toujours d’autres modèles à tester.

L’objectif d’un PoC n’est pas de produire le modèle parfait, mais bien de permettre de répondre à la question suivante : “mon niveau d’incertitude sur le potentiel business et la faisabilité technique du projet a-t-il été suffisamment baissé pour me permettre de prendre une décision concernant la création d’un produit de bout en bout ?”

Et pour répondre à cette question, pas besoin d’attendre le modèle parfait. Il est nécessaire de contraindre les PoCs dans le temps afin de se forcer à “lever les crayons” régulièrement et se demander s’il est absolument nécessaire de réinvestir un peu de temps d’exploration ou bien si on a levé suffisamment d’incertitudes pour se mettre en ordre de bataille pour créer un MVP en production.

Des Use Cases peu actionnables par le business

Très souvent, les projets data se focalisent sur les performances algorithmiques et autres enjeux techniques plutôt que sur la manière dont les résultats seront exploités par les utilisateurs finaux.

Combien de fois un Data Scientist s’est-il posé la question suivante : “Hum, avec quel type de camembert ou d’histogramme sympathique je vais bien pouvoir faire comprendre mes résultats au métier ?”.

S’assurer qu’un produit data soit réellement exploitable par les utilisateurs finaux est tout aussi importante quel le reste de la chaîne. Et c’est même un point sur lequel la majorité de l’énergie doit être mise dès le début. S’asseoir à côté de ses utilisateurs, comprendre la manière dont ils travaillent et de quoi ils ont besoin pour être capable de prendre des décisions informées par la data, voilà des étapes qui manquent trop souvent.

Penser à la manière dont les résultats seront activés par les utilisateurs permet de mieux dimensionner ses développements par la suite. Quelle Data Viz est-elle la plus pertinente ? Est-ce que l’explicabilité des prédictions est un critère essentiel ? Parlons-nous d’une nouvelle interface ou bien faut-il absolument être incorporés à des outils existants ?

Une trop grande complexité (voir incompatibilité) à industrialiser les développements

Dernier cité, mais pas des moindres, il n’est pas rare de constater un mode de fonctionnement où des Data Scientists travaillent “en chambre”, puis donnent ensuite leurs travaux à des Data Engineers afin d’industrialiser le tout. Au-delà du fait que ce mode de fonctionnement ne fait qu’agrandir les silos, c’est aussi un risque fort d’un point de vue technique.

En effet, que faire si le package utilisé change de version ? Que faire si il n’est pas compatible avec les environnements de production ? Quid d’une dégradation des performances si l’on doit changer de langage ? Que faire si le temps de calcul est beaucoup trop long pour que le modèle soit utilisé en conditions réelles ?

Il est bien dommage de se rendre compte de ces problématiques seulement après que de longs mois d’exploration aient été passés.

L’arrêt d’un PoC fait partie du processus, mais il doit être géré avec méthode : Fail Fast and iterate

Comme on peut le voir, il est possible de réduire drastiquement les risques d’échec à la mise en production des produits data grâce à une bonne organisation tant produit que technique.

Mais même en ayant cela en tête, beaucoup de projets Data ne passeront pas le stade du PoC. Et c’est normal !

Tous les projets data ne sont pas destinés à devenir de véritables produits data qui délivrent de la valeur en production. La décision de l’abandon d’un PoC fait partie du processus de Discovery en Data. L’arrêt en soi n’est pas une mauvaise chose, et est porteur d’enseignements essentiels, qui vous permettront de faire des choix en conscience, de faire pivoter votre vision produit, ou bien de passer à une autre problématique.

Ce qui compte, c’est la discipline mise en place afin de faire en sorte de “fail fast”, et d’en tirer des enseignements au plus tôt afin de pivoter et de garantir les succès futurs.

La gestion des phases exploratoires dans les projets data doit donc se faire avec méthode. Entre autres, nous recommandons de les contraindre drastiquement dans le temps afin de se forcer à lever les crayons et de s’assurer que le temps investit soit absolument nécessaire. Les enseignements retirés et analyses faites doivent de plus être scrupuleusement documentés et partagés, afin de ne pas réinventer la roue à chaque nouveau projet.

Si vous êtes sur des projets agiles, la notion de “spike” (unité de temps dédiée à travailler sur un sujet que l’on ne peut pas estimer car trop incertain) peut être utilisée, mais associée à une question précise à laquelle répondre. Vous déciderez ensuite, en équipe, s’il est nécessaire d’investir sur un autre spike ou bien si les principales incertitudes ont été levées.

En résumé, il est temps de redonner ses lettres de noblesses au Proof of Concept ! Le fait qu’un projet n’aille pas en production ne signifie pas que c’est un échec tant qu’on en retire des conclusions actionnables 🙂

‍

🙏 Cliquez ici vous avez aimé cet article, aidez nous à gagner en visibilité en le partageant sur Linkedin 🙏