De l’agilité tout au long de la chaine applicative : DevOps
Photo by Alvaro Reyes on Unsplash
Depuis de nombreuses années, les cycles de développement informatique sont devenus agiles. Cycles plus courts, focalisation sur des objectifs plus atteignables, vérification continue de la réponse aux besoins de l’utilisateur, les méthodes agiles vont bien au-delà des concepts gadgets de « sprint » ou de réunions tenues debout.
Pour appliquer ces méthodes à la phase de test et de mise en production des applications, a été inventé le DevOps. Le DevOps établit un pont entre le développement et la mise en production, au lieu de voir ces deux phases comme opposées. Plutôt que de « livrer » une application achevée, puis de prévoir les tests, et la mise en production, les trois phases sont imbriquées, au travers de cycles courts.
Les tests et le déploiement de l’application se font pas à pas, de manière itérative, et au sein d’un processus d’amélioration continue. D’une part les tests sont réalisés dès les phases de développement. Ils sont donc plus efficaces et les erreurs peuvent être corrigées plus rapidement. Une fois testée, la partie de l’application concernée peut être présentée aux utilisateurs. Leur retour est immédiat, et intégré dans le prochain cycle. De trois phases séparées : développement, tests, puis mise en production ; on passe à l’enchainement de cycles courts intégrant les trois phases dans un processus de développement continu. Ce processus devra bien sûr être outillé, et lui-même être accompagné par la mise en place de ses propres indicateurs de mesure de son efficacité.
Les projets décisionnels ont toujours été, même bien avant l’invention des concepts d’agilité, basés sur des cycles de développement interactifs et itératifs. A la fin des années 90, lorsque j’ai eu la chance de travailler pour Patrick Bensabat, chez Business & Decision, il était déjà question de ces cycles de développement imbriqués, clefs de l’atteinte d’objectifs que les clients avaient eux-mêmes du mal à définir par avance.
Si l’on devait choisir un nom à l’application de la méthode DevOps aux projets d’analyse de données, ce serait clairement le DataOps. Dès 2013, le terme « DataOps » apparait dans quelques rapports, comme celui de Manoranjan Panda, qui précise que « DataOps cherche à intégrer l'ingénierie des données, l'intégration des données, la qualité des données, la sécurité des données et la confidentialité des données aux opérations. Il applique les principes de DevOps, du développement agile et du contrôle statistique des processus, utilisés dans la production allégée, pour améliorer la durée du cycle d'extraction de la valeur des analyses de données ».
En 2014, le terme « DataOps » est défini comme « l'ensemble des meilleures pratiques qui améliorent la coordination entre la science des données et les opérations », par Madhumita Dash et R.N. Panda dans un article intitulé «The Big Data in the Cloud and Hadoop Technology».
De son côté, Andy Palmer y consacre un article complet de son blog en 2015 : From DevOps to DataOps.
Pour appliquer ces méthodes à la phase de test et de mise en production des applications, a été inventé le DevOps. Le DevOps établit un pont entre le développement et la mise en production, au lieu de voir ces deux phases comme opposées. Plutôt que de « livrer » une application achevée, puis de prévoir les tests, et la mise en production, les trois phases sont imbriquées, au travers de cycles courts.
Les tests et le déploiement de l’application se font pas à pas, de manière itérative, et au sein d’un processus d’amélioration continue. D’une part les tests sont réalisés dès les phases de développement. Ils sont donc plus efficaces et les erreurs peuvent être corrigées plus rapidement. Une fois testée, la partie de l’application concernée peut être présentée aux utilisateurs. Leur retour est immédiat, et intégré dans le prochain cycle. De trois phases séparées : développement, tests, puis mise en production ; on passe à l’enchainement de cycles courts intégrant les trois phases dans un processus de développement continu. Ce processus devra bien sûr être outillé, et lui-même être accompagné par la mise en place de ses propres indicateurs de mesure de son efficacité.
Les projets décisionnels ont toujours été, même bien avant l’invention des concepts d’agilité, basés sur des cycles de développement interactifs et itératifs. A la fin des années 90, lorsque j’ai eu la chance de travailler pour Patrick Bensabat, chez Business & Decision, il était déjà question de ces cycles de développement imbriqués, clefs de l’atteinte d’objectifs que les clients avaient eux-mêmes du mal à définir par avance.
Si l’on devait choisir un nom à l’application de la méthode DevOps aux projets d’analyse de données, ce serait clairement le DataOps. Dès 2013, le terme « DataOps » apparait dans quelques rapports, comme celui de Manoranjan Panda, qui précise que « DataOps cherche à intégrer l'ingénierie des données, l'intégration des données, la qualité des données, la sécurité des données et la confidentialité des données aux opérations. Il applique les principes de DevOps, du développement agile et du contrôle statistique des processus, utilisés dans la production allégée, pour améliorer la durée du cycle d'extraction de la valeur des analyses de données ».
En 2014, le terme « DataOps » est défini comme « l'ensemble des meilleures pratiques qui améliorent la coordination entre la science des données et les opérations », par Madhumita Dash et R.N. Panda dans un article intitulé «The Big Data in the Cloud and Hadoop Technology».
De son côté, Andy Palmer y consacre un article complet de son blog en 2015 : From DevOps to DataOps.
Les particularités des projets de science des données
Si le développement d’une application transactionnelle métier passe encore par les phases classiques de cahier des charges, analyses, développement, etc ; une application de science des données répond à des contraintes différentes.
Bien souvent le cahier des charges est limité, voir inexistant. Difficile en effet de prévoir l’ensemble des besoins alors même que la phase d’investigation pourrait les confirmer mais aussi infirmer leur faisabilité. L’agilité est l’essence même d’un projet de science des données.
Les data scientists sont à la fois là pour mettre en place des outils demandés par les utilisateurs, mais également pour imaginer des solutions originales, à des besoins plus ou moins bien exprimés. Le data scientist ne peut être efficace s’il est contraint par un cahier des charges, une analyse fonctionnelle et un cycle de mise en production trop rigides. Au travers d’un « bac à sable » développé pour lui permettre de manipuler des données en toute sécurité, le data scientist enchaine les PoC (Proofs of Concept). Point essentiel : il a le droit à l’erreur. Elle est même obligatoire ! Car un PoC finalement trop éloigné de ses objectifs finaux permet d’éviter plus de développement qui se révèleraient inutiles.
Autre point important, les technologies utilisées. Dans les domaines de l’apprentissage machine, de l’apprentissage profond, les outils évoluent très vite. Le data scientist doit pouvoir adopter rapidement de nouvelles technologies, et les tester sans trop de contraintes.
Il faut en réalité séparer le socle des outils d’analyse. Le socle doit être géré par la direction informatique – on parle souvent de data factory ou de data platform, suivant que l’on englobe l’organisation ou que l’on désigne uniquement la partie informatique – et permettre l’automatisation de la mise en production des PoC une fois qu’ils sont validés. Ce socle doit être stable. En revanche, plus de flexibilité doit être accordée dans l’usage de nouveaux outils, techniques ou algorithmes, permettant de transformer la donnée en connaissance.
Bien souvent le cahier des charges est limité, voir inexistant. Difficile en effet de prévoir l’ensemble des besoins alors même que la phase d’investigation pourrait les confirmer mais aussi infirmer leur faisabilité. L’agilité est l’essence même d’un projet de science des données.
Les data scientists sont à la fois là pour mettre en place des outils demandés par les utilisateurs, mais également pour imaginer des solutions originales, à des besoins plus ou moins bien exprimés. Le data scientist ne peut être efficace s’il est contraint par un cahier des charges, une analyse fonctionnelle et un cycle de mise en production trop rigides. Au travers d’un « bac à sable » développé pour lui permettre de manipuler des données en toute sécurité, le data scientist enchaine les PoC (Proofs of Concept). Point essentiel : il a le droit à l’erreur. Elle est même obligatoire ! Car un PoC finalement trop éloigné de ses objectifs finaux permet d’éviter plus de développement qui se révèleraient inutiles.
Autre point important, les technologies utilisées. Dans les domaines de l’apprentissage machine, de l’apprentissage profond, les outils évoluent très vite. Le data scientist doit pouvoir adopter rapidement de nouvelles technologies, et les tester sans trop de contraintes.
Il faut en réalité séparer le socle des outils d’analyse. Le socle doit être géré par la direction informatique – on parle souvent de data factory ou de data platform, suivant que l’on englobe l’organisation ou que l’on désigne uniquement la partie informatique – et permettre l’automatisation de la mise en production des PoC une fois qu’ils sont validés. Ce socle doit être stable. En revanche, plus de flexibilité doit être accordée dans l’usage de nouveaux outils, techniques ou algorithmes, permettant de transformer la donnée en connaissance.
Les spécificités des données cibles de l’investigation
Industrialiser le cycle de vie des données décisionnelles n’est pas chose aisée. Elles sont différentes, et j’oserai dire, plus complexes car protéiformes, que des données transactionnelles de production.
Bien sur les données de production font partie des données décisionnelles : factures, paies, commandes, livraisons, etc. sont à la base de la construction de l’entrepôt de données de l’entreprise.
Mais aujourd’hui, lorsque l’on parle de science des données, on voit beaucoup plus loin que les données de production.
Reprenons un instant le cycle de création d’une donnée de production. Il y a encore quelques décennies, c’était relativement simple. Une donnée créée entrait dans le système de production au travers d’un ID, un numéro de client, un numéro de commande… ce qui permettait de créer l’enregistrement dans une base relationnelle. Une fois transférée dans l’entrepôt de données, la donnée restait rattachée à cet ID.
Aujourd’hui de nombreuses données sont créées sans être rattachées à un ID, ou sans qu’il soit possible de le connaitre immédiatement. Ces données doivent être rattachées plus tard, et leur cycle de vie est bien différent des données de production.
On peut citer :
- Les données imparfaites, générées à partir d’algorithmes d’apprentissage machine, affectées d’un pourcentage de probabilité ;
- Les données non analysées, que l’on conserve, dans le but d’en extraire plus tard de la connaissance, mais qui restent dans un premier temps des données brutes ;
- Les données sur les non-actions, comme les abandons de paniers dans le commerce électronique ; ou les produits commandés, payés, puis finalement retournés avant paiement.
La data factory doit intégrer l’ensemble de ces cas, afin de proposer au data scientist une plateforme globale, sans qu’il ne soit tenté, ou contraint de créer de nouveaux silos à côté.
Le principal avantage de cette plateforme de préparation de données, est de permettre de conduire des tests dans un environnement le plus proche possible des conditions de la mise en production.
Les jeux de tests sont créés sur la plateforme, participent aux PoCs, et servent ensuite de base aux phases de vérification du bon fonctionnement de l’application.
Attention ici à bien respecter les contraintes du RGPD si vous gérez des données personnelles : « privacy by design » afin de vous assurer que tout ce que vous développez sera conforme au RGPD ; et anonymisation de l’ensemble des jeux de tests contenant des données personnelles. Rappelez-vous que la première faille RGPD, déclarée en 2018 par Orange, était justement liée à l’absence d’anonymisation d’un fichier de test d’une nouvelle application !
Bien sur les données de production font partie des données décisionnelles : factures, paies, commandes, livraisons, etc. sont à la base de la construction de l’entrepôt de données de l’entreprise.
Mais aujourd’hui, lorsque l’on parle de science des données, on voit beaucoup plus loin que les données de production.
Reprenons un instant le cycle de création d’une donnée de production. Il y a encore quelques décennies, c’était relativement simple. Une donnée créée entrait dans le système de production au travers d’un ID, un numéro de client, un numéro de commande… ce qui permettait de créer l’enregistrement dans une base relationnelle. Une fois transférée dans l’entrepôt de données, la donnée restait rattachée à cet ID.
Aujourd’hui de nombreuses données sont créées sans être rattachées à un ID, ou sans qu’il soit possible de le connaitre immédiatement. Ces données doivent être rattachées plus tard, et leur cycle de vie est bien différent des données de production.
On peut citer :
- Les données imparfaites, générées à partir d’algorithmes d’apprentissage machine, affectées d’un pourcentage de probabilité ;
- Les données non analysées, que l’on conserve, dans le but d’en extraire plus tard de la connaissance, mais qui restent dans un premier temps des données brutes ;
- Les données sur les non-actions, comme les abandons de paniers dans le commerce électronique ; ou les produits commandés, payés, puis finalement retournés avant paiement.
La data factory doit intégrer l’ensemble de ces cas, afin de proposer au data scientist une plateforme globale, sans qu’il ne soit tenté, ou contraint de créer de nouveaux silos à côté.
Le principal avantage de cette plateforme de préparation de données, est de permettre de conduire des tests dans un environnement le plus proche possible des conditions de la mise en production.
Les jeux de tests sont créés sur la plateforme, participent aux PoCs, et servent ensuite de base aux phases de vérification du bon fonctionnement de l’application.
Attention ici à bien respecter les contraintes du RGPD si vous gérez des données personnelles : « privacy by design » afin de vous assurer que tout ce que vous développez sera conforme au RGPD ; et anonymisation de l’ensemble des jeux de tests contenant des données personnelles. Rappelez-vous que la première faille RGPD, déclarée en 2018 par Orange, était justement liée à l’absence d’anonymisation d’un fichier de test d’une nouvelle application !
Rattachez tout cela aux principes de gouvernance
S’il est un mot qui revient dans toutes les réunions des « data offices », c’est celui de gouvernance. Une gouvernance des données qui n’est plus simplement informatique, mais orientée métiers. La mise en place de cette data factory doit être vue comme une étape de la gouvernance.
La traçabilité de l’ensemble des opérations qui y sont réalisées, l’analyse d’impact liée aux personnes, aux données, et aux processus, et la mise en place des indicateurs de suivi de la qualité des données, concourent tous à une meilleure gouvernance.
Parmi les fonctions de cette gouvernance, on s’attachera à mettre en place un MDM (Master Data Management), une gestion de données de références. Ce MDM, intégré à la data factory, permettra de se mettre d’accord sur une définition commune de ces données. Et de partager leur valeur au sein des applications. Un MDM à jour est un des facteurs clefs de succès d’une mise en production rapide des applications, qui s’appuient sur des définitions de données claires et publiées.
La gestion des métadonnées, permettra de tracer les usages des données à l’intérieur du système. Elle n’est pas directement un facteur clef de succès d’une méthode DevOps, mais participe activement à la compréhension des incidents lors des phases de test.
Quant à la partie conformité, elle concerne bien sur le RGPD, mais aussi les règles propres à votre secteur d’activité (très précises par exemple dans la banque et l’assurance).
Tout cela devra être piloté. Un bon « DataOps » passe par la mise en place d’indicateurs de suivi et d’alertes. Il s’agit presque d’un projet de tableau de bord en lui-même, au-dessus des applications décisionnelles. Tout comme les phases de développement agiles disposent de leurs outils de mesure d’avancement ; les phases de tests et de mise en production devront également être contrôlées. Objectif : vérifier que les délais annoncés répondent aux besoins des utilisateurs, tout en ne mettant en production que des applications testées et sécurisées. Et finalement cela n’a rien d’une quadrature du cercle : en écoutant et comprenant les contraintes des deux parties, les équipes data et les équipes de production informatique peuvent parfaitement œuvrer de concert pour accélérer la mise en production.
La traçabilité de l’ensemble des opérations qui y sont réalisées, l’analyse d’impact liée aux personnes, aux données, et aux processus, et la mise en place des indicateurs de suivi de la qualité des données, concourent tous à une meilleure gouvernance.
Parmi les fonctions de cette gouvernance, on s’attachera à mettre en place un MDM (Master Data Management), une gestion de données de références. Ce MDM, intégré à la data factory, permettra de se mettre d’accord sur une définition commune de ces données. Et de partager leur valeur au sein des applications. Un MDM à jour est un des facteurs clefs de succès d’une mise en production rapide des applications, qui s’appuient sur des définitions de données claires et publiées.
La gestion des métadonnées, permettra de tracer les usages des données à l’intérieur du système. Elle n’est pas directement un facteur clef de succès d’une méthode DevOps, mais participe activement à la compréhension des incidents lors des phases de test.
Quant à la partie conformité, elle concerne bien sur le RGPD, mais aussi les règles propres à votre secteur d’activité (très précises par exemple dans la banque et l’assurance).
Tout cela devra être piloté. Un bon « DataOps » passe par la mise en place d’indicateurs de suivi et d’alertes. Il s’agit presque d’un projet de tableau de bord en lui-même, au-dessus des applications décisionnelles. Tout comme les phases de développement agiles disposent de leurs outils de mesure d’avancement ; les phases de tests et de mise en production devront également être contrôlées. Objectif : vérifier que les délais annoncés répondent aux besoins des utilisateurs, tout en ne mettant en production que des applications testées et sécurisées. Et finalement cela n’a rien d’une quadrature du cercle : en écoutant et comprenant les contraintes des deux parties, les équipes data et les équipes de production informatique peuvent parfaitement œuvrer de concert pour accélérer la mise en production.