5 minutes de lecture 3 oct. 2017
hacking computer network

La chaîne de blocs est-elle la clé du succès du modèle DevOps?

Par Abhishek Sinha

Associé, leader national, Technologies du secteur bancaire, EY Canada

Leader senior spécialiste de l’incidence transformationnelle des technologies dans divers secteurs Rêveur. Visionnaire. Père.

5 minutes de lecture 3 oct. 2017

Afficher les ressources

Les vieux modèles de développement logiciel ne sont plus adaptés à un monde qui évolue vite. Combiner processus DevOps et chaîne de blocs peut aider.

De nos jours, pour rester concurrentiel, il faut pouvoir suivre le rythme de l’automatisation des activités et de la transformation de la technologie. Si l’on ajoute le besoin d’évoluer sans cesse tout en réagissant rapidement aux disruptions perpétuelles dans le secteur, en plus de continuer de respecter les exigences en matière de contrôles tout au long du cycle de développement et de production – il peut sembler que la bataille n’est jamais gagnée. 

L’idéal est de commencer par un projet pilote pour utiliser la chaîne de blocs correctement. Adopter une approche itérative permet de contrôler la portée, l’incidence et les risques à chaque étape du processus.
Abhishek Sinha
Associé, leader national, Technologies du secteur bancaire, EY Canada

Dans les faits, le modèle traditionnel de développement de logiciel « en cascade » n’est plus adapté au contexte actuel. Nombre de grandes entreprises optent plutôt pour des processus DevOps bimodaux. Elles peuvent ainsi accélérer le cycle de développement de logiciel tout en assurant un développement agile, une gestion continue du changement et un déploiement rapide. Le modèle DevOps, qui a la particularité de combiner le développement logiciel (« dev ») et les opérations (« ops »), offre un immense potentiel pour l’ensemble de ces applications. Mais il apporte aussi son lot de nouveaux défis, en tête desquels figurent les politiques de séparation des tâches, qui représentent l’un des principaux obstacles à une transformation plus rapide.

Chez EY, nous envisageons de nouvelles façons puissantes de tirer parti de la chaîne de blocs. Les combinaisons bimodales de processus DevOps mis en œuvre dans une chaîne de blocs permettront une conformité transparente avec la séparation des tâches, améliorant à la fois l’agilité et l’efficacité de la livraison.

Conçue à l’origine pour permettre l’échange de cryptomonnaie, la technologie de la chaîne de blocs est bâtie sur des principes de la cryptographie, de la théorie des jeux et des réseaux de pair à pair. La nature même de la chaîne de blocs fait en sorte qu’elle offre nativement des fonctionnalités qui peuvent facilement être étendues pour mettre en œuvre des contrôles, existants et nouveaux, conformes aux exigences réglementaires de séparation des tâches. Cet avantage peut changer la donne pour les organisations qui cherchent à exploiter la puissance de l’automatisation des processus pour accroître la rapidité de livraison, réduire les coûts et continuer de respecter les exigences en matière de contrôles.

Comment commencer à jeter un pont entre DevOps et la chaîne de blocs

Les organisations qui adoptent DevOps et envisagent la mise en œuvre d’une solution DevOps d’entreprise ayant recours à la chaîne de blocs (« DECB ») doivent commencer par définir un modèle de confiance pour leur organisation. La raison est que la transformation des capacités existantes – ou l’adoption de nouvelles capacités – nécessite de procéder à l’identification des fonctions internes qui sont dignes de confiance et de celles qui ne le sont pas.

L’application d’une solution fondée sur la chaîne de blocs doit toujours être amorcée par les fonctions qui sont jugées moins dignes de confiance. Dans un contexte de processus de livraison de technologie, l’analyse, le développement, les tests et le déploiement sont des fonctions moins dignes de confiance. Les fonctions jugées dignes de confiance peuvent exécuter les contrôles dans des réseaux avec permissions. La direction, la gestion du changement et l’audit sont des fonctions de surveillance et de contrôles qui sont plus dignes de confiance.

À cette étape, l’idéal est de commencer par un projet pilote. Une approche itérative en matière d’adoption du DevOps permet de contrôler la portée, l’incidence et les risques à chaque étape du processus. 

Ce qu’il faut garder à l’esprit pendant le déploiement du projet pilote

Chaque itération doit exécuter six étapes essentielles afin d’accélérer l’adoption du modèle et, au bout du compte, assurer le succès de l’implémentation d’une solution DECB :

1. Définir la portée
Cette étape établit une compréhension des rôles en matière de livraison au sein de l’entreprise et des activités respectives. Elle définit aussi une étape durable des processus DevOps bimodaux une fois l’itération terminée.

2. Concevoir une feuille de route
Il faut avoir une feuille de route pour chaque activité du processus de livraison qui doit générer une transaction dans la solution DECB. C’est ce qui permet de délimiter les rôles et les droits d’accès.

3. Mettre en œuvre en tenant compte des règles
Il faut mettre en œuvre par intégration des règles additionnelles dans les contrats intelligents, nouveaux ou existants, dans la solution DECB et ajouter des nœuds pour inclure tout participant additionnel au modèle de livraison DevOps bimodal.

4. Effectuer des tests
Les tests utilisent les données des étapes précédentes pour produire une analyse des conflits entre les rôles et activités établis et les politiques de séparation des tâches existantes. Dans les résultats, les conflits avec les politiques de séparation des tâches doivent être classés par utilisateur, par rôle, par groupe ou par activité. Cette analyse sert habituellement aux tests de conformité présentés à la direction, aux auditeurs et aux organismes de réglementation.

5. Atténuer pour limiter l’incidence
Réfléchir à l’incidence potentielle d’un conflit avec les politiques de séparation des tâches est essentiel. Cette étape peut être réalisée en parallèle avec l’étape de correction ou être réalisée en dernier, quand les conflits ont été réduits au minimum.

6. Corriger avant de passer à une autre itération
La correction, qui doit viser à résoudre de façon permanente les conflits avec les politiques de séparation des tâches, comprend la redéfinition des rôles, le nettoyage des rôles, l’évaluation de la pertinence d’un utilisateur ou la mise à jour des politiques de séparation des tâches en fonction des exigences en matière de contrôles. Il n’y a pas de pratique de pointe ou de méthode prescrite pour la correction des conflits. La correction se présente habituellement dans deux catégories : le nettoyage tactique de la population d’utilisateurs et la redéfinition des rôles stratégiques. La composante tactique peut se réaliser rapidement, tandis que la redéfinition des rôles suppose habituellement de nombreux changements organisationnels parmi les gens, les processus et les technologies.

Aller de l’avant pour libérer le potentiel de la chaîne de blocs

Dans un environnement de développement et de déploiement rapides de logiciels, un modèle bien conçu de livraison DevOps bimodal fondé sur le risque, déployé grâce à la solution DECB, permet d’assurer la conformité, d’améliorer les contrôles et de simplifier les principaux processus de livraison. Cela peut accroître l’efficacité et l’agilité d’une organisation de façon très percutante.

Les politiques de séparation des tâches demeurent une partie intégrante des contrôles internes d’une organisation. Ces politiques ont été pensées pour répondre aux exigences réglementaires et aux exigences en matière de contrôles, qui visent à prévenir la fraude et les anomalies significatives. Ces réglementations prévoient la mise en place de contrôles pour éviter qu’une seule personne dispose de droits excessifs lui permettant d’exécuter des stratégie et transactions dans l’ensemble d’un processus d’affaires sans mesures de contrôle et d’imputabilité dignes de confiance.

De nombreuses organisations connaissent des difficultés avec leurs politiques de séparation des tâches existantes. D’une part, elles doivent respecter les exigences en matière de contrôles, mais, d’autre part, elles ont un besoin pressant de devenir plus agiles et d’accéder plus rapidement au marché. En outre, la complexité de mettre en œuvre un changement dans plusieurs systèmes d’une entreprise fait en sorte que de nombreuses organisations ont de la difficulté à mettre en place des contrôles internes de base.

De nos jours, les organisations doivent trouver un juste équilibre entre les efforts et l’attention qu’elles doivent porter à la conformité avec leurs politiques actuelles de séparation des tâches et le désir de simplicité et de précision dans l’exécution des contrôles. Une adhésion aveugle aux directives internes définies plus de dix ans auparavant pourrait s’avérer une erreur coûteuse qui empêcherait les grandes organisations de profiter des avantages du modèle DevOps, particulièrement celles qui comptent plusieurs gammes de services.

La technologie de la chaîne de blocs est idéale pour mettre en œuvre un modèle de livraison DevOps bimodal qui répond aux exigences en matière de contrôles dans les environnements d’affaires et technologiques de toutes les tailles. Un processus de livraison bien compris, axé sur les rôles, documenté et automatisé n’est qu’une exigence et, lorsqu’il est mis en œuvre dans une chaîne de blocs au moyen de contrats intelligents, il fournit une traçabilité immuable des activités de livraison approuvées.

Résumé

Devant le besoin de rapidité qui continue d’influencer le marché, la technologie de la chaîne de blocs constitue un excellent moyen de mettre en œuvre un modèle de livraison DevOps bimodal qui répond aux exigences en matière de contrôles dans les environnements d’affaires et technologiques de toutes tailles. Décortiquer le modèle pour en comprendre le potentiel pourrait apporter de réels avantages à votre organisation.

À propos de cet article

Par Abhishek Sinha

Associé, leader national, Technologies du secteur bancaire, EY Canada

Leader senior spécialiste de l’incidence transformationnelle des technologies dans divers secteurs Rêveur. Visionnaire. Père.