Du PoC à l’industrialisation des projets Data

Du PoC à l’industrialisation des projets Data

1 – QU’EST CE QU’UN POC?

Si vous entendez parler de PoC, c’est pour Proof of Concept. Le but d’un PoC est de prouver qu’un processus ou un concept apporte une réelle valeur ajoutée. Cela permet de se projeter en faisant un test sur un périmètre restreint, d’en analyser les résultats, de prendre rapidement des mesures correctives si nécessaire, de mesurer la valeur ajoutée, puis éventuellement de proposer une mise à l’échelle de la solution et un déploiement en masse.

Un PoC représente un gain de temps, un gain d’argent et une faible prise de risque. En effet, le PoC est synonyme de gain de temps car le développement et la mise en place de ce test sont rapides, suivant le format d’un MVP (Minimum Viable Product). Enfin, un PoC représente aussi une faible prise de risque car le budget alloué reste peu élevé sur une courte durée. Cela permet d’avoir une mesure avec des résultats et une vision plus claire tout en facilitant le chiffrage du projet, puisque l’objet est aussi de tester les points techniques : par exemple les connecteurs de données et l’intégration d’un jeu de données réduit mais néanmoins représentatif. Ceci réalisé, il est possible de prendre une décision en toute connaissance de cause et de décider d’investir davantage, de changer d’échelle et de déployer plus largement.

2 – Démarche d’un POC DATA : 

Concrètement, prenons l’exemple d’un de nos clients, souhaitant tester sa capacité à vérifier l’intégrité de ses données de manière automatisée pour réduire le nombre de traitements manuels. Nous l’avons accompagné pour identifier l’architecture data la plus adéquate, son développement et son implémentation. Plutôt que de mener le projet dans sa globalité directement, nous avons décidé de développer et de mettre en œuvre un PoC en créant les bases d’un DataLake et son pendant sur des solutions DatawareHouse et en traitant les données avec des technologies adaptée au contexte Big Data pour détecter les anomalies potentielles. Cela nous a permis de :

  • démontrer que la solution est techniquement faisable en validant certains éléments au détriment d’autres. Les solutions permettant de gérer des volumes de données importants sont nombreux. Dans le contexte de notre client le choix a été d’associer un datalake à Databricks,le tout sous Azure. Ici le Poc était à mi-chemin entre le benchmark (des tests snowflake ou sql server ont ainsi pu être menés) et l’étude complète.

 

  •  de tester ses capacités sur son propre jeu de données, d’identifier les éléments d’architecture à retenir et les points de complexité à traiter pour converger vers la solution la plus appropriée à sa situation. Une fois le PoC validé, nous avons ajusté la démarche et continué à accompagner ce client dans la mise en place de ce nouveau processus et de son système associé en lui proposant la mise en place de bonnes pratiques, de normes et d’outils de déploiement.

Plus généralement, la mise en place de POC permet à nos clients souhaitant migrer des modèles de données rigides (basés sur des solutions qui ne sont parfois plus supportées par les éditeurs ou tout simplement trop chers) vers des technologies plus récentes et agiles, de tester et d’itérer rapidement avant une prise de décision et d’identifier rapidement la valeur ajoutée à tirer de ces nouvelles technologies. Cela permet aux équipes techniques de valider leurs capacités à monter en compétences sur de nouvelles technologies et aux utilisateurs métiers de manipuler plus facilement des données et créer des tableaux de bord simplement.

Pour les utilisateurs métiers, le choix d’une solution de dataviz  peut aussi faire l’objet d’un POC déroulé selon une démarche calibrée entre plusieurs solutions disponibles sur le marché à partir d’un jeu de donnée parlant pour le métier.

 

  3 – QUAND ARRÊTER UN POC ?

Le PoC n’est pas comme un projet ou un programme qui peut s’étendre sur plusieurs mois voire années. Le but ici est bien de faire un test sur une courte période en faisant abstraction d’un certain nombre de contraintes (l’exploitation, le déploiement,…). Ainsi, dès que les hypothèses du PoC sont testées, retravaillées et validées au final ; il est alors temps de clore le PoC pour prendre une décision : soit ne pas poursuivre, soit passer en phase d’industrialisation. Pour repérer ce moment, il faut sentir lorsque l’on s’approche d’un prototype stable, où le but du concept est atteint.

  4 – QUELS SONT LES FACTEURS CLÉS DE SUCCÈS ?

Point primordial pour avoir davantage de chance de déployer le PoC à grande échelle : réussir à embarquer les Métiers, qui joueront alors le rôle d’ambassadeur pour le déploiement futur, sans oublier les équipes techniques qui devront valider les orientations. Il est important que les équipes collaborent et soient décloisonnées, exit les silos ! Par ailleurs, pour impliquer au mieux les équipes et pouvoir les embarquer plus aisément, il est indispensable de bien communiquer sur le projet du PoC, son but, le planning et le rôle que chacun y jouera. Il parait alors essentiel de rappeler aux équipes que le PoC existe pour tester un concept. Il ne donnera pas forcément de suite et ne sera pas forcément généralisé.

La cohésion au projet au niveau opérationnel est ainsi nécessaire ; mais, décrocher un sponsorship à un haut niveau de management permet lui aussi d’avoir plus de chance de mettre en place le PoC. En effet, cela peut alors s’intégrer à la stratégie globale de l’entreprise, anticiper d’éventuels changements à venir et peut aider pour obtenir des enveloppes budgétaires. Ce niveau de soutien permettra alors aussi de sécuriser le concept et de s’assurer d’avoir les capacités d’industrialiser l’innovation si celle-ci est pertinente et viable.

L’intérêt d’un PoC est de pouvoir réagir rapidement. Dans le cadre d’un POC sur des projets data (mise en place d’un Datalake ou d’une base de donnée, implémentation d’un Data Catalog, outil de Data Quality, outil de Datavisualisation), il est primordial d’embarquer rapidement les utilisateurs finaux du concept (Data Steward, CDO, et les équipes d’architecture SI) et de mener des tests utilisateurs pour avoir leur retour d’expérience sur le concept imaginé. En effet, ce sont bien les utilisateurs finaux qui sauront au mieux conseiller et aider au bon développement du concept en travaillant main dans la main avec les équipes techniques pour que la solution réponde au mieux à leurs besoins. Il faut garder à l’esprit que ce sont eux qui ont la réponse ou la solution.

5 – QUELS SONT LES FREINS POTENTIELS AU DÉVELOPPEMENT D’UN POC ?

Savoir entraîner les Métiers dans ce PoC et éviter leur refus d’adoption est fondamental. Pour cela, il faut parfois savoir agilement utiliser des méthodes de conduite du changement ; ou savoir jouer de la communication pour convaincre et maintenir cette tension positive qui maintient leur intérêt.

Il paraît aussi nécessaire de faire valider et de sécuriser les besoins, les disponibilités et les ressources aussi physiques que budgétaires en termes d’infrastructures et d’investissements financiers.

Faire un PoC ne signifie pas expérimenter tous azimuts. Cela entraînerait la perte de sens, un risque de tromper les Métiers et de décevoir les utilisateurs finaux ; sans compter, les investissements en temps et budget non fructueux !

Partager cette publication