Jean Baylon
Plusieurs définitions existent, et si celle des 3V (volume, variété et vélocité ou vitesse) est la plus souvent citée, on retrouve aussi sa version officieuse : quand les solutions standards ne répondent plus au besoin du client sur des problématiques de performance, de volumes, d'hétérogénéité des sources ou encore d'impératifs de (quasi) temps réel. Evidemment, l'enjeu est de taille : l'existant en banque, finance et assurance est suffisamment conséquent pour ne pas sauter sur la première technologie à la mode. La pérennité de la solution est une nécessité absolue, tout comme son coût, le support fourni, etc.
Mais fondamentalement, il ne peut y avoir de Big Data que s'il y a une volonté métier avérée : on ne fait pas du Big Data parce que sa DSI est avide de nouveaux défis techniques, ou parce que ses concurrents sont plus en avance sur le sujet. Il faut au préalable se poser la question de ce genre de solution technique lorsqu’un besoin métier émerge, tels que les projets transverses ou ceux relevant d'une vue globale.
Prenons l’exemple d’une compagnie d’assurance, il existe très probablement une application de suivi des clients, une pour les sinistres automobiles, une autre pour la responsabilité civile, ou encore une pour la partie habitation. Mais qu'en est-il des questions de type vision client 360 ? Derrière ce nom un peu ronflant se cache une réalité très simple : connaître le client dans toutes ses interactions avec l'entreprise pour pouvoir lui proposer les services les plus personnalisés et adaptés à ses besoins. S’il s'agit d'un enjeu à la fois simple et stratégique, il nécessite cependant de connaître les données de toutes les applications du système d’informations concernées.
De même, dans le cas de la banque, les équipes spécialisées pourraient disposer d'une vue globale des services de trading de l'entreprise et réaliser ainsi une couverture de risque plus fine, en s'appuyant sur toutes les données du système d’informations, au lieu de vues partielles et dépendantes de l'existant applicatif. Ce besoin métier se résoud par la mise en place d'une architecture adaptée, les data lakes.
Dans le domaine du Big Data, on peut dégager trois grands niveaux de maturité chez les clients :
- Hésitant : le Big Data est à l'état de POC, réalisé ou à venir. Cette solution s'envisage comme une urgence, parce que le système d’informations ne tient plus ou comme une solution technique pour réaliser des projets plus ambitieux, dépassant le cloisonnement très fort du système existant.
- Initié : la solution est mise en place, en général sous la forme de data lake. Elle est développée en parallèle du SI standard, et les deux ont quelques interactions. C'est le cas par exemple, d’un grand groupe français de la banque finance qui utilise son lake comme moteur de fraude complémentaire de son existant, ou encore pour avoir une mesure plus fine de sa pertinence commerciale (hit ratio).
- Intégré (ou Alchimiste) : dans ce dernier cas, le data lake dont nous parlions plus haut est au cœur du système d'information. Il répond en temps quasi réel aux requêtes métier (par exemple, que recommander à un client ?) et son existence provoque la décommission d'applications existantes à son profit. Il s'agit de véritable maîtrise du Big Data et avec elle, la possibilité d'avoir une grande partie du socle applicatif d'un bloc, parfaitement intégré aux besoins métier.
Lors d’un projet Big Data, les difficultés qui apparaissent sont de plusieurs types :
- Méthodologiques avant tout : mettre en place un tel projet va mettre en avant une équipe avec de nouveaux besoins clients, pertinents dans l'ensemble, qu'il va falloir creuser, affiner, et prioriser. Dans ce contexte, une prestation Agile peut prendre tout son sens et aider l'équipe à faire face à un backlog particulièrement conséquent. De même, une prestation de conseil Big Data peut également porter sur cet axe. Par exemple, il est toujours plus aisé de convaincre son DSI de la justesse d’un investissement après un audit d’un SI, si bien sûr le dit audit s’avère concluant…
- Relatives à l'infrastructure : nous pensons bien sûr aux coûts, mais pas seulement. Ce serait mentir que de prétendre que les briques techniques telles que Flume, Sqoop, Oozie et consors sont parfaitement exemptes de bugs. Le support est un moyen qui fera une différence majeure dans vos choix techniques, mais il ne peut en aucun cas se substituer à la maîtrise de vos équipes et à leur faculté à trouver des solutions parallèles, parfois de secours. L'expertise est certes nécessaire, mais il faudra aussi miser sur des collaborateurs astucieux. Rappelons enfin une évidence : un data lake est la cible privilégiée d’une attaque extérieure qui cherchera à recueillir le maximum de données stratégiques. Il faut donc impérativement penser « sécurité » dès la mise en place de la solution et surtout pas après coup.
- Organisationnelles : le recrutement s'anticipe, en particulier sur un écosystème comme Hadoop pour lequel une bonne connaissance d'une dizaine de produits n'est pas un luxe. La structuration des équipes deviendra inévitable quand le projet gagnera en importance et en maturité. Si l'aventure se pérennise pour atteindre un niveau de maturité suffisant et substituer un data lake à l'existant, il faudra alors gérer les impacts humains, voire les restructurations d'équipes. Ce projet Big Data engage donc sur long terme.
- Conceptuelles, enfin : même s'il existe des analogies, le Big Data n'est pas une énorme base de données relationnelle standard, mieux écrite et distribuée.
Oui, il existe des outils comme Phoenix, ou le SQL de Hive, laissant apparaître la facilité d’une architecture trois tiers des plus classiques, alors qu’il n'en est rien. Un projet réussi passe par une méthode de développement adaptée : on pré calcule ses données, on réalise des POCs sur les problématiques de Machine Learning qu'on intègre ensuite à l'existant dans des langages éventuellement différents. La démarche sera beaucoup plus itérative, les tests de performance ou de qualité seront un impératif. Par exemple, le NYSE doit stocker tous les jours 1 To de données supplémentaire et doit être en mesure d'absorber 10000 transactions utilisateur par seconde.
Bien évidemment, après avoir listé toutes ces difficultés, nous aimerions finir sur une note positive. Nous voyons dans ce genre d'architecture une extraordinaire opportunité. Au-delà de la technique et au-delà d'un budget Big Data à prévoir assez conséquent, il y a la possibilité de revenir aux fondamentaux de son métier. Imaginez que votre entreprise soit en mesure de faire parler les données de tous services confondus. La question n'est pas de trouver les meilleures modalités de stockage ou de calculs, mais bien de laisser aller son imagination vers ce qui fait l'essence même de l'entreprise :
- Comment économiser en infrastructure pour réinvestir dans le cœur de métier de l'entreprise ? Rajiv Tiwari, dans son livre, Hadoop for Finance Essentials évoque des gains possibles de 90 % en stockage par To et par an.
- Réalise-t-elle correctement son métier ? Quelles sont ses principales pistes d'amélioration ? Par rapport aux comportements bancaires de ses clients, où se situe la vraie valeur de son offre ? Quels sont ses produits ou services les plus pertinents ? Sont-ils tous bien exploités ? Quels nouveaux produits ou services proposer ? En disposant d’une vision client à 360°, il devient enfin possible de bâtir des offres croisées et plus adaptées.
- Quelles sont les évolutions du secteur ? De sa clientèle ? Que propose la concurrence ? L'analyse des sources externes (twitter par exemple ou encore toutes autres sources publiques pertinentes) offre une nouvelle façon de réaliser des opérations marketing et des lancements de produit plus adaptés. Il devient également possible d'affiner son recrutement en analysant les CV reçus, ainsi que le profil et l’évolution de carrière de ses propres employés.
En un mot, il est temps de simplifier son SI, tout en gagnant en introspection sur son propre métier. A ce jour, le Big Data est l’une des pistes techniques les plus prometteuses pour orienter sa stratégie et ouvrir sur de nouvelles perspectives de rentabilité.
Par Jean BAYLON chez SOAT
Mais fondamentalement, il ne peut y avoir de Big Data que s'il y a une volonté métier avérée : on ne fait pas du Big Data parce que sa DSI est avide de nouveaux défis techniques, ou parce que ses concurrents sont plus en avance sur le sujet. Il faut au préalable se poser la question de ce genre de solution technique lorsqu’un besoin métier émerge, tels que les projets transverses ou ceux relevant d'une vue globale.
Prenons l’exemple d’une compagnie d’assurance, il existe très probablement une application de suivi des clients, une pour les sinistres automobiles, une autre pour la responsabilité civile, ou encore une pour la partie habitation. Mais qu'en est-il des questions de type vision client 360 ? Derrière ce nom un peu ronflant se cache une réalité très simple : connaître le client dans toutes ses interactions avec l'entreprise pour pouvoir lui proposer les services les plus personnalisés et adaptés à ses besoins. S’il s'agit d'un enjeu à la fois simple et stratégique, il nécessite cependant de connaître les données de toutes les applications du système d’informations concernées.
De même, dans le cas de la banque, les équipes spécialisées pourraient disposer d'une vue globale des services de trading de l'entreprise et réaliser ainsi une couverture de risque plus fine, en s'appuyant sur toutes les données du système d’informations, au lieu de vues partielles et dépendantes de l'existant applicatif. Ce besoin métier se résoud par la mise en place d'une architecture adaptée, les data lakes.
Dans le domaine du Big Data, on peut dégager trois grands niveaux de maturité chez les clients :
- Hésitant : le Big Data est à l'état de POC, réalisé ou à venir. Cette solution s'envisage comme une urgence, parce que le système d’informations ne tient plus ou comme une solution technique pour réaliser des projets plus ambitieux, dépassant le cloisonnement très fort du système existant.
- Initié : la solution est mise en place, en général sous la forme de data lake. Elle est développée en parallèle du SI standard, et les deux ont quelques interactions. C'est le cas par exemple, d’un grand groupe français de la banque finance qui utilise son lake comme moteur de fraude complémentaire de son existant, ou encore pour avoir une mesure plus fine de sa pertinence commerciale (hit ratio).
- Intégré (ou Alchimiste) : dans ce dernier cas, le data lake dont nous parlions plus haut est au cœur du système d'information. Il répond en temps quasi réel aux requêtes métier (par exemple, que recommander à un client ?) et son existence provoque la décommission d'applications existantes à son profit. Il s'agit de véritable maîtrise du Big Data et avec elle, la possibilité d'avoir une grande partie du socle applicatif d'un bloc, parfaitement intégré aux besoins métier.
Lors d’un projet Big Data, les difficultés qui apparaissent sont de plusieurs types :
- Méthodologiques avant tout : mettre en place un tel projet va mettre en avant une équipe avec de nouveaux besoins clients, pertinents dans l'ensemble, qu'il va falloir creuser, affiner, et prioriser. Dans ce contexte, une prestation Agile peut prendre tout son sens et aider l'équipe à faire face à un backlog particulièrement conséquent. De même, une prestation de conseil Big Data peut également porter sur cet axe. Par exemple, il est toujours plus aisé de convaincre son DSI de la justesse d’un investissement après un audit d’un SI, si bien sûr le dit audit s’avère concluant…
- Relatives à l'infrastructure : nous pensons bien sûr aux coûts, mais pas seulement. Ce serait mentir que de prétendre que les briques techniques telles que Flume, Sqoop, Oozie et consors sont parfaitement exemptes de bugs. Le support est un moyen qui fera une différence majeure dans vos choix techniques, mais il ne peut en aucun cas se substituer à la maîtrise de vos équipes et à leur faculté à trouver des solutions parallèles, parfois de secours. L'expertise est certes nécessaire, mais il faudra aussi miser sur des collaborateurs astucieux. Rappelons enfin une évidence : un data lake est la cible privilégiée d’une attaque extérieure qui cherchera à recueillir le maximum de données stratégiques. Il faut donc impérativement penser « sécurité » dès la mise en place de la solution et surtout pas après coup.
- Organisationnelles : le recrutement s'anticipe, en particulier sur un écosystème comme Hadoop pour lequel une bonne connaissance d'une dizaine de produits n'est pas un luxe. La structuration des équipes deviendra inévitable quand le projet gagnera en importance et en maturité. Si l'aventure se pérennise pour atteindre un niveau de maturité suffisant et substituer un data lake à l'existant, il faudra alors gérer les impacts humains, voire les restructurations d'équipes. Ce projet Big Data engage donc sur long terme.
- Conceptuelles, enfin : même s'il existe des analogies, le Big Data n'est pas une énorme base de données relationnelle standard, mieux écrite et distribuée.
Oui, il existe des outils comme Phoenix, ou le SQL de Hive, laissant apparaître la facilité d’une architecture trois tiers des plus classiques, alors qu’il n'en est rien. Un projet réussi passe par une méthode de développement adaptée : on pré calcule ses données, on réalise des POCs sur les problématiques de Machine Learning qu'on intègre ensuite à l'existant dans des langages éventuellement différents. La démarche sera beaucoup plus itérative, les tests de performance ou de qualité seront un impératif. Par exemple, le NYSE doit stocker tous les jours 1 To de données supplémentaire et doit être en mesure d'absorber 10000 transactions utilisateur par seconde.
Bien évidemment, après avoir listé toutes ces difficultés, nous aimerions finir sur une note positive. Nous voyons dans ce genre d'architecture une extraordinaire opportunité. Au-delà de la technique et au-delà d'un budget Big Data à prévoir assez conséquent, il y a la possibilité de revenir aux fondamentaux de son métier. Imaginez que votre entreprise soit en mesure de faire parler les données de tous services confondus. La question n'est pas de trouver les meilleures modalités de stockage ou de calculs, mais bien de laisser aller son imagination vers ce qui fait l'essence même de l'entreprise :
- Comment économiser en infrastructure pour réinvestir dans le cœur de métier de l'entreprise ? Rajiv Tiwari, dans son livre, Hadoop for Finance Essentials évoque des gains possibles de 90 % en stockage par To et par an.
- Réalise-t-elle correctement son métier ? Quelles sont ses principales pistes d'amélioration ? Par rapport aux comportements bancaires de ses clients, où se situe la vraie valeur de son offre ? Quels sont ses produits ou services les plus pertinents ? Sont-ils tous bien exploités ? Quels nouveaux produits ou services proposer ? En disposant d’une vision client à 360°, il devient enfin possible de bâtir des offres croisées et plus adaptées.
- Quelles sont les évolutions du secteur ? De sa clientèle ? Que propose la concurrence ? L'analyse des sources externes (twitter par exemple ou encore toutes autres sources publiques pertinentes) offre une nouvelle façon de réaliser des opérations marketing et des lancements de produit plus adaptés. Il devient également possible d'affiner son recrutement en analysant les CV reçus, ainsi que le profil et l’évolution de carrière de ses propres employés.
En un mot, il est temps de simplifier son SI, tout en gagnant en introspection sur son propre métier. A ce jour, le Big Data est l’une des pistes techniques les plus prometteuses pour orienter sa stratégie et ouvrir sur de nouvelles perspectives de rentabilité.
Par Jean BAYLON chez SOAT
Les médias du groupe Finyear
Lisez gratuitement :
Le quotidien Finyear :
- Finyear Quotidien
La newsletter quotidienne :
- Finyear Newsletter
Recevez chaque matin par mail la newsletter Finyear, une sélection quotidienne des meilleures infos et expertises en Finance innovation, Blockchain révolution & Digital transformation.
Les 6 lettres mensuelles digitales :
- Le Directeur Financier
- Le Trésorier
- Le Credit Manager
- The Chief FinTech Officer
- The Chief Blockchain Officer
- The Chief Digital Officer
Le magazine trimestriel digital :
- Finyear Magazine
Un seul formulaire d'abonnement pour recevoir un avis de publication pour une ou plusieurs lettres
Le quotidien Finyear :
- Finyear Quotidien
La newsletter quotidienne :
- Finyear Newsletter
Recevez chaque matin par mail la newsletter Finyear, une sélection quotidienne des meilleures infos et expertises en Finance innovation, Blockchain révolution & Digital transformation.
Les 6 lettres mensuelles digitales :
- Le Directeur Financier
- Le Trésorier
- Le Credit Manager
- The Chief FinTech Officer
- The Chief Blockchain Officer
- The Chief Digital Officer
Le magazine trimestriel digital :
- Finyear Magazine
Un seul formulaire d'abonnement pour recevoir un avis de publication pour une ou plusieurs lettres