»Olivier Bourgeois

À propos de Olivier Bourgeois

Cet auteur n'a pas encore renseigné de détails.
Jusqu'à présent Olivier Bourgeois a créé 15 entrées de blog.

Test Automation et analyse de code source : pourquoi mettre en place un nouveau portail de qualité ?

Par Nick Blamey | 27 Novembre 2018

Quality Gate

Quels enjeux pour les développeurs et pourquoi DevOps est une nécessité – un article de Nick Blamey, directeur des opérations en Europe du Nord chez ARCAD.

L’enjeu business :  La qualité continue des applications dépend de la mise en œuvre de politiques qui imposent une validation immédiate.  Mais les DSI responsables des divers actifs applicatifs manquent de lignes directrices sur la façon dont ils doivent mesurer la qualité du code, ainsi que des ressources à allouer à cette activité.

Qualité Continue (CQ) et DevOps

Les défaillances logicielles augmentent considérablement le coût du développement d’applications. Trouver et corriger les erreurs de production est souvent 100 fois plus coûteux que de les trouver et de les corriger pendant les phases de conception et de codage.  Il est essentiel que les équipes intègrent la qualité à toutes les phases du développement logiciel et automatisent autant que possible la vérification de la qualité pour déceler les défauts tôt dans le processus et éviter les efforts répétés.  C’est ce que l’on entend par « Qualité Continue » ou CQ, qui constitue aujourd’hui une garantie essentielle – ou une garantie de qualité – dans les cycles de livraison rapides des workflows DevOps et CI/CD.

Quelles sont les techniques disponibles pour la Qualité Continue ?

L’analyse statique du code est la méthode la plus simple et la plus efficace pour prévenir les défauts et sécuriser le code tout en accélérant l’exécution des applications.

L’automatisation de l’analyse du code dès la phase de construction ou d’intégration continue permet à votre équipe de détecter et de corriger les défauts systémiques lorsque le coût de remédiation est à son plus bas. Après l’investissement initial dans la configuration des règles et des métriques, les gains d’efficacité deviennent exponentiels tout au long du cycle de développement.

Pour atteindre une qualité continue, les organisations peuvent employer un certain nombre de stratégies :

  • Analyse statique du code source pour identifier les points chauds de complexité, les déviations des normes, les failles de sécurité, etc.
  • Examens par les pairs pour vérifier le code afin de s’assurer qu’il répond à des critères précis
  • Tests unitaires pour exécuter et examiner les modules individuels, ou unités d’une application, pour en vérifier le bon fonctionnement
  • Test de régression pour répéter un ensemble de scénarios de test sur une nouvelle version d’application afin d’identifier tout écart par rapport au fonctionnement normal
  • Suivi de l’application en production pour s’assurer de son bon fonctionnement après chaque mise à jour et à tout moment

Pour être efficace dans un environnement DevOps, chacune des techniques ci-dessus doit être à la fois automatisée et continue, intégrée au workflow CI/CQ/CD.

Quelle est l’importance de l’analyse du code source (SCA) pour DevOps ?

Analyse du code source : quelles alternatives ?

Face au défi de l’audit de qualité d’une base de code IBM i existante, les DSI ont un nombre limité de choix :

  • Processus complexe d’examen par les pairs : même soutenu par des outils collaboratifs, l’effort manuel d’un examen par les pairs peut être difficile à gérer au sein de grandes équipes possédant un large éventail d’expertise.
  • Audit externe du code source par des experts : faute de connaissances applicatives, la courbe d’apprentissage des auditeurs externes est souvent trop longue, ce qui en fait une option coûteuse aux avantages souvent non quantifiables.
  • Analyse continue du code source à l’aide d’une solution automatisée conçue spécifiquement pour une base de code IBM i RPG.

Le coût des défaillances dans le développement des applications

Une étude sur la qualité des logiciels réalisée par Capers Jones en 2008 a abouti à deux conclusions très importantes :

  • Le  » gaspillage  » du développement et les correctifs de défauts (à partir du code déployé) ont absorbé près des deux tiers de la main-d’œuvre informatique américaine, ne laissant qu’un tiers pour le travail productif sur de nouveaux projets.
  • 50 % des budgets des projets de développement de logiciels sont consacrés à la correction de codes de mauvaise qualité ; moins de 6 % des organisations ont mis en place des processus de gestion de logiciels clairement définis ; et les projets logiciels de la taille de 100 000 points fonctionnels échouent à 65%.

Des articles plus récents sur ce sujet suggèrent que pour de nombreuses organisations, les statistiques sont restées pratiquement inchangées aujourd’hui.

Depuis que DevOps est devenu le moteur clé de la plupart des développements, il existe un énorme potentiel d’optimisation pour éliminer les défis décrits ci-dessus et rendre les développeurs plus efficaces dans leur travail en passant plus de temps à coder et moins à réparer les défauts.

Les limites des tests fonctionnels

La plupart des organisations effectuent des tests fonctionnels de leurs applications par le biais de l’interface utilisateur, requis pour des raisons de conformité.  Cependant, comme le test de la boîte noire, puisque chaque défaut doit être diagnostiqué à partir de l’interface utilisateur, cette approche n’apporte que peu d’informations pour aider les développeurs à résoudre réellement les problèmes. Le résultat est typiquement un flux constant de défauts classés comme :

  • Ne peut pas reproduire le problème
  • L’environnement de test n’est pas correctement configuré
  • Besoin de plus d’informations

Avec une information médiocre pour les développeurs, les défis sont repoussés en aval.  Les projets sont confrontés à des retards dus à une durée de compréhension du code trop longue et à une approche de débogage sous-optimale. Cela limite considérablement la capacité de toute équipe de développement IBM i à maintenir la « vitesse de livraison » nécessaire pour atteindre ses objectifs DevOps.

Analyse du code statique : Qui le fait et pourquoi ?

Il existe 3 approches principales de l’analyse de code statique dans le monde multi-plateforme : Analyse statique pour la sécurité, Analyse statique pour la complexité du code et Analyse statique pour la qualité du code.

De nombreux produits existent pour accomplir cette tâche et le marché est vaste et en expansion avec quelques acteurs dominants. Les solutions sont souvent extrêmement coûteuses et ont tendance à être moins pertinentes sur IBM i qui est moins sensible aux problèmes de sécurité que les autres plateformes.

IBM AppScan Source est le meilleur exemple du leader du marché de la sécurité du code, mais MicroFocus propose également Fortify Security Suite avec un certain nombre d’outils supplémentaires disponibles chez d’autres fournisseurs, tels que CheckMarx, Klocwork, CA Veracode.

En ce qui concerne la complexité des codes, les principaux acteurs sont CAST et McCabe, mais ni l’un ni l’autre n’offre de support pour le RPG sur IBM i.

Pourquoi les développeurs IBM i ont-ils besoin d’une analyse du code source ?

Compte tenu des multiples variantes du RPG et de la longévité des applications, les développeurs d’IBM i font face à un défi unique avec des bases de code Legacy contenant des millions de lignes de code qui ont été maintenues pendant parfois trente ans par des développeurs successifs.  Il est laborieux de comprendre la logique du programme et d’évaluer la qualité du code – les ressources sont détournées pour traiter la  » dette technique  » de la base de code.  Le défi est d’autant plus grand que les compétences en RPG sont de plus en plus rares sur le marché.  La nouvelle syntaxe Free Form RPG a changé le jeu, offrant un moyen d’intégrer une nouvelle génération de développeurs – faisant de la conversion des applications RPGLE en Free Form la « plate-forme brûlante » de notre époque.

L’analyse du code source en tant qu’élément clé de tout « audit de base de code Legacy »

L’analyse du code source peut être réalisée dans le cadre d’un processus plus large de vérification du code source.  Des entreprises comme ARCAD ont construit des solutions qui génèrent une vue d’ensemble complète des métadonnées de l’ensemble de la base de code, permettant un niveau d’analyse et de contrôle d’intégrité plus approfondi.  Ici, l’analyse du code source est livrée dans le cadre de l’audit du code et les règles et métriques sont utilisées pour faire respecter les standards locaux.

ARCAD CodeChecker peut créer un Code Quality Baseline à partir duquel le RPG Code Base peut être continuellement amélioré par une mesure précise et régulière de la qualité du code. Cela permet aux DSI et aux responsables du développement de montrer aux propriétaires d’applications qu’ils respectent constamment les objectifs d’amélioration continue ISO 27001 de l’organisation au sens large.

Élargissez votre réseau pour prendre en compte les problèmes de qualité du code pour les RPG

Comme décrit plus haut, le RPG est un cas particulier dans le monde du développement.  Parmi les outils d’analyse de code source standard, quelques-uns (comme SonarCube) sont capables d’effectuer une simple révision de code RPG et une analyse de qualité statique, mais ils sont très limités dans leur périmètre (par exemple, le manque de support des nombreuses variantes RPG) et le nombre de règles qu’ils peuvent appliquer (limité à environ une trentaine, pour la plupart des règles de documentation du code).

Le risque business potentiel de ces outils limités est le suivant :

  • Ils ne sont pas vraiment utilisables pour l’application des lignes directrices sur la qualité des codes, en particulier pour RPG
  • Ils ont tendance à créer un certain nombre de faux résultats qui limitent leur efficacité et pourraient en théorie éliminer toute valeur introduite dans le processus d’évaluation par les pairs, en forçant les développeurs à déboguer les problèmes qui sont causés par l’outil lui-même

Les organisations DevOps modernes recherchent maintenant une solution  » industrielle performante  » à ce défi pour s’assurer qu’une implémentation d’un outil d’analyse de code open source ne devienne pas elle-même un goulot d’étranglement dans le workflow DevOps.

Les objectifs de conception d’ARCAD Code Checker ont donc été de s’adapter aux grandes équipes de développement modernes DevOps orientées IBM i RPG, en se concentrant sur :

  • Le balayage rapide de l’ensemble d’une base de code
  • L’ auto-ajustement des règles de qualité pour l’application sur une base de code par base de code, étape par étape.
  • L’ apport d’une valeur réelle aux développeurs qui effectuent le travail de codage par un feedback rapide de leur travail après chaque édition. (voir la section ci-dessous)
  • L’intégration en toute transparence dans une chaîne plus large d’outils ARCAD DevOps, complète et rapide de référencement X et d’audit, de gestion du code source, de création de dépendances, de tests automatiques (avec diagnostic en profondeur des erreurs) et de gestion de l’environnement IBM i LPAR (Déploiement et Release Automation)

Création de valeur rapide pour votre CodeBase avec ARCAD CodeChecker

Gains de productivité grâce à l’analyse du code source et à l’application du Quality Gate

Typiquement, si un développeur sait dans les minutes qui suivent l’écriture du code qu’une directive n’a pas été respectée avec un produit de vérification de code comme ARCAD CodeChecker, il peut résoudre les problèmes immédiatement avec un impact minimal sur la qualité. Si le code est « revu par les pairs », un développeur peut attendre des jours, voire des semaines, avant de recevoir un retour d’information, et il sera passé ensuite à d’autres tâches. La meilleure analogie serait un correcteur grammatical avec traitement de texte, c’est-à-dire que si vous savez immédiatement, en écrivant un texte, que vous avez commis une erreur grammaticale, vous pouvez la corriger immédiatement pendant que la phrase est encore dans votre esprit – comparé au temps qu’il vous faudra pour effectuer une vérification grammaticale 2 semaines après avoir écrit la phrase. Dans ce cas, le rédacteur du texte consacrera 90% du temps de vérification grammaticale et de correction à essayer de comprendre le contexte de ce qu’il a écrit 2 semaines auparavant.

Piloter l’application de la Qualité du Code en offrant une valeur réelle et immédiate aux développeurs

De nombreux outils d’analyse de code source ont une mauvaise réputation. Les DSI et les responsables du développement doivent constamment prendre des décisions en matière de gestion des risques entre : le ralentissement du processus de développement et la pression des dirigeants pour maintenir la fréquence des livraisons ou le risque d’engendrer des dettes techniques qui pourraient causer un risque important à l’avenir si les directives de qualité du code ne sont pas respectées.

Code Checker d’ARCAD a été conçu pour apporter une valeur ajoutée immédiate directement dans l’espace de travail / bureau du développeur grâce à son intégration avec RDi et SEU. ARCAD a conçu Code Checker pour répondre aux commentaires réguliers des développeurs RPG « Si vous allez noter mes devoirs, au moins dites-moi comment vous allez juger mon succès ou mon échec ».

En plus de l’optimisation du processus d’évaluation par les pairs grâce à l’analyse statique automatique de la qualité du code, ARCAD CodeChecker peut offrir de la valeur aux développeurs et à vos projets en cours :

  • La création et l’application des directives de qualité du code source fournies automatiquement évitent la nécessité d’un examen par les pairs : les développeurs peuvent se concentrer sur le codage plus rapidement que sur l’examen par les pairs.
  • La mise en place d’un processus d’analyse du code source pour l’élimination de la dette technique permet à l’équipe IBM i RPG de rester en phase avec les autres équipes de l’organisation dans un monde DevOps.

Combiner l’analyse du code source avec l’automatisation des tests, le contrôle de l’intégrité des bases de données et aider les développeurs à déboguer plus rapidement les problèmes complexes.

Les équipes de développement modernes sont confrontées à ce problème

DevOps Bottleneck effect from manual Source Code Analysis, Testing, and Debugging, re-test cycle

L’effet de goulot d’étranglement de DevOps à partir de l’analyse, du test, du débogage et du cycle de re-test manuels du code source

Pour faire face à l’accélération des cycles DevOps de quelques versions par an à des versions plus régulières, mensuelles ou même hebdomadaires, les organisations sont amenées à effectuer des tests plus réguliers, normalement fournis par l’automatisation.  Ils sont également poussés à se libérer d’une grande partie des efforts consacrés à la « localisation des défauts » pour s’assurer que les développeurs puissent générer un code de meilleure qualité sans impact sur les délais requis par les propriétaires des applications.

« Shift left » comme facteur clé pour DevOps :

Le graphique ci-dessous montre un graphique typique de défauts IBM i / RPG, soit le volume de défauts qui surviennent entre le début du projet et la date de sortie réelle.

Cost of defects across the development lifecycle

Coût des défauts tout au long du cycle de développement

Bien que 85 % des défauts soient généralement introduits dans les premières phases de codage du cycle DevOps, le coût de réparation des défauts augmente de façon exponentielle au cours des phases ultérieures de test et de livraison, atteignant des coûts incroyablement élevés quand un défaut est détecté en production, avec potentiellement un impact significatif sur le bénéfice net et la réputation des sociétés.

Il est clair qu’avec un « shifting left » de détection des défauts, leur coût et leur impact sont minimisés.

ARCAD Software, à travers son travail avec de nombreuses équipes de développement sur RPG, a constaté que les développeurs effectuent un certain nombre de tâches pour faire progresser la détection des erreurs. Il s’agit notamment de :

  • L’unité de codage manuel se teste elle-même afin de tester les fonctionnalités de chaque programme et de s’assurer qu’elles n’ont pas créé de défauts au fur et à mesure de leur développement.
  • Les processus de test de Batch individuels continuent de fonctionner après que des modifications aient été apportées à des programmes spécifiques.
  • Reconfigurer et travailler avec des données de test complexes, y compris les exigences d’anonymisation.
  • Référencer des défauts sur une multitude de composants / programmes pour comprendre l’impact de chaque changement de code sur les autres programmes RPG et aussi sur les références NON -IBM i x.
  • Scripter le déploiement du nouveau code une fois compilé sur les différents LPARS (dev, QA, Prod, etc.) et effectuer ensuite un contrôle manuel qui, une fois déployé, permet à chacun des LPARS de fonctionner pleinement. Ce processus est généralement appelé « assurance de l’environnement de test ».
  • Préparer le LPAR pour une exécution de test de bout en bout complète, y compris les tests de charge et les tests fonctionnels de bout en bout.

Pourtant, selon l’expérience d’ARCAD, chacun de ces processus, lorsqu’ils sont exécutés manuellement, entraîne des coûts, des efforts et des risques supplémentaires de goulots d’étranglement dans un processus de déploiement DevOps.

Pour faire face à ces défis, ARCAD offre un certain nombre d’outils en complément de CodeChecker (analyse du code source) pour éliminer les goulots d’étranglement dans le processus DevOps et fournir un processus sans failles depuis les spécifications fonctionnelles vers le codage, le test unitaire, la compilation, le développement, le contrôle final et la production de déploiement :

  • ARCAD Verifier (BATCH et UI Testing)
  • ARCAD DOT Anonymizer,
  • ARCAD Observer pour le référencement X
  • ARCAD Builder and Drops pour l’automatisation du déploiement et le Release Management

Chacune de ces solutions peut apporter une valeur ajoutée à votre processus de développement, le « Shifting Left » réduisant ainsi le coût global dans le cycle de développement :

Contribution of ARCAD solutions to a “shift left” of development costs

Contribution des solutions ARCAD à un «Shift Left» des coûts de développement

SpareBank Success Story

SpareBank a réduit ses coûts de gestion de l’environnement et de conformité de 70%

Témoignage client

SpareBank1 accélère ses cycles de développement sur IBM i avec ARCAD for DevOps

Témoignage client

Vue et positionnement d’ARCAD

En tant qu’entreprise, ARCAD a entamé son évolution en corrigeant le problème de l’analyse du code source des changements de format de date de l’an 2000. Depuis lors, ARCAD a fourni des solutions aux défis les plus brûlants et les plus actuels auxquels nos plus de 350 clients sont confrontés avec leurs bases de code RPG : X référencement, audit, gestion du code source, Build, test et déploiement.

ARCAD for DevOps: suite of solutions integrated over a repository core

ARCAD pour DevOps: suite de solutions intégrées sur un noyau référentiel

ARCAD Steps

Suggestion de prochaine étape :

Un processus d’audit en utilisant l’expertise et l’outillage d’ARCAD est un excellent point de départ pour votre cheminement vers un processus DevOps de qualité.

Pour en savoir plus sur la façon dont ARCAD a conçu ses solutions pour résoudre le prochain problème dans l’analyse du code source, contactez ARCAD et découvrez comment CodeChecker et d’autres outils ARCAD DevOps pour IBM i peuvent vous aider avec vos processus de CodeReview, Audit, Testing et DevOps.

Nick Blamey

Nick Blamey

Directeur des opérations d’ARCAD pour l’Europe du Nord

Nick Blamey a rejoint ARCAD après avoir travaillé chez IBM où il était responsable de DevOps et de Rational Solutions dans différentes fonctions en Europe. Auparavant, Nick a travaillé pour d’autres outils de développement de logiciels, notamment : HP / MicroFocus, Fortify Software (acquis par HP), Empirix (acquis par Oracle), Radview et Segue (maintenant Microfocus). Nick est un leader d’opinion dans les domaines de l’analyse du code statique, de l’automatisation des tests, DevOps et des stratégies « Shift-Left ».

2018-12-28T11:41:19+00:00 Blog|

Une introduction au Data Masking – Infographie

Par Olivier Bourgeois | 26 Décembre 2018

Les données augmentent continuellement et les violations de données concernent toutes les industries. De ce fait, des réglementations émergent et se concentrent sur la protection des données et de la vie privée. Découvrez comment le Data Masking peut résoudre ces problèmes.

Infographie - Une introduction au Data Masking
DOT-Anonymizer Datasheet

Dot Anonymizer Datasheet

Datasheet

L’anonymisation des données personnelles est un sujet de plus en plus sensible. DOT-Anonymizer vous accompagne pour protéger la confidentialité de vos données de test, cette documentation vous présente son fonctionnement.

Téléchargez la Datasheet

2018-12-31T13:01:54+00:00 Blog|

5 clés pour une modernisation réussie de votre IBM i

par Alexandre Codinach | 27 septembre 2018


Les projets de modernisation d’application réussis sont ceux qui permettent de trouver le juste équilibre entre objectifs IT et business.
Ils peuvent se traduire de différentes manières :

  • Amélioration de la maintenabilité, de l’évolutivité et de la scalabilité du système
  • Adoption des nouveaux outils et méthodes de développement
  • Réduction des risques et des coûts opérationnels
  • Réduction du time to business
  • Amélioration de la satisfaction client et de leur productivité
  • Simplification des processus de recrutement

Quelle que soit la raison d’un projet de modernisation d’un système « Legacy » comme IBM i, il est important d’identifier en amont certains points essentiels à la réussite du projet :

1. Obtenir le soutien de la Direction Générale

Quel que soit son périmètre, un projet de modernisation est un projet d’entreprise qui dépasse les seules problématiques de l’ IT. Les enjeux concernent la performance de l’entreprise, son développement voire parfois sa survie, même si son contenu peut se révéler quelque peu abscons pour le profane.

Conseil : Vulgariser, traduire les enjeux pour l’entreprise en évaluant les impacts courts termes (moins de livrables) et le Retour Sur Investissement à l’issue du projet

2. Définir un schéma directeur global de modernisation

Dans un tel projet, tout ne doit ou ne peut être modernisé.

Il n’y a pas une modernisation mais des modernisations. L’approche ne doit pas être manichéenne. Modernisation de l’existant, réécriture et/ou progicialisation ne sont pas forcément incompatibles.

La bascule du neuf au moderne n’existe pas. Le jour du renouveau dans 3 ans est un fantasme. C’est une démarche continue, jalonnée, qui doit alterner quick wins et objectifs à plus long terme

Conseil : Communiquer pour que chacun dans l’entreprise visualise et comprenne les enjeux. Associer les ressources métiers et définir des indicateurs métiers est un plus.

3. Dégager des ressources, associer les métiers

Comme tout projet, même externalisé, une modernisation consomme de la ressource.

Au-delà de la technique, c’est une conduite globale de changement qu’il faut réaliser en partant de l’IT jusqu’aux métiers dont le rapport à l’outil peut considérablement changer et impacter leur quotidien.

Conseil : Associer les collaborateurs dès les phases d’analyse pour qu’ils adhèrent et soient partie prenante des décisions puis les premiers relais de communication auprès des équipes

4. … Et sécuriser en automatisant

Pendant les travaux, la vente continue : moderniser ne signifie pas suspendre les projets et ne plus délivrer de nouvelles fonctionnalités nécessaires aux métiers.

Automatiser le cycle de vie de vos applications réduit les risques et augmente la productivité des acteurs du SI en les concentrant sur les travaux à plus-value. Au final, Il permet donc de dégager des ressources plus facilement.

Un déploiement et une intégration continue (CI/CD) vous permettront de raccourcir les temps de développement et sécuriseront la fiabilité des applications en production.

5. Tester la non-régression

Les équipes internes et parfois métiers sont les seules aptes à fournir des scénarios utiles pour les tests de non-régression. Préparez ces scénarios avec soin en amont du projet.

Vous devez pouvoir vérifier que la modernisation effectuée, quelle que soit son ampleur, n’a pas entraîné d’effets de bord non prévus qui pourraient dégrader le comportement de votre application.

Exécutez à nouveau ces tests lors de la modernisation et vérifiez l’absence d’erreurs.

Enfin, si vous optez pour un accompagnement par des équipes externes pour votre projet, exigez une garantie de non-régression.

Vous devez vous assurer que le système répondra toujours aux exigences.

Conseil : Capitalisez sur l’investissement nécessaire pour ce projet pour structurer la démarche de test de votre entreprise

Conclusion

  • Communiquez et légitimez votre projet
  • Lors de la définition du périmètre de votre projet, effectuez un audit fonctionnel en complément de l’audit technique
  • Anticipez les besoins en ressources pour mener à bien votre projet
  • Sécurisez en automatisant afin d’assurer la disponibilité pour vos utilisateurs finaux
  • Vérifiez que le système répond aux exigences grâce aux tests de non-régression
Modernization as a Service White Paper

Modernization as a Service

White Paper

Découvrez les solutions aux problèmes liés à la maintenance quotidienne de vos applications IBM i sur IBM Power Systems.

Télécharger le White Paper
Enterprise Modernization for IBM i

Enterprise Modernization for IBM i

Brochure

Grâce à la modernisation d’entreprise, les organisations IBM i peuvent exploiter leur avantage compétitif et leurs investissements en R&D sur une plateforme sûre et unique, stratégiquement positionnée sur les technologies mobiles et cloud.

Lire la brochure

Alexandre Codinach

Alexandre Codinach

VP Sales and Operations Americas

Alexandre Codinach a 30 ans d’expérience IBM i technique et managériale, avec une expertise spécialisée dans le domaine de la modernisation IBM i. Avec une vue à 360 degrés sur IBM i, Alexandre a occupé de nombreux postes, notamment dans l’architecture d’application, la gestion de projet, l’avant-vente et le conseil. En tant que COO d’ARCAD, sa connaissance approfondie de la technologie IBM i et sa capacité à coordonner des projets IBM i complexes de grande envergure et à l’échelle internationale font de lui un conseiller de confiance dans le déploiement des projets ARCAD « Modernisation as a Service » dans le monde entier.

2018-12-06T09:44:06+00:00 Blog|

L’avènement de l’Enterprise DevOps : relever le défi des silos IT

Par Olenka Van Schendel | 19 novembre 2018

null

En 2018, le problème du silo informatique persiste.  Le fossé entre les initiatives numériques et le développement du Legacy épuise les budgets informatiques et entraîne des livraisons incohérentes vers la production.

Les erreurs détectées à ce niveau ont un impact business direct : le coût moyen d’un incident majeur d’une application logicielle stratégique en production par heure est de 1 M$, soit dix fois le coût horaire moyen de dysfonctionnement matériel (*).  Et étonnamment, 70 % des erreurs de production sont dues à des erreurs de déploiement, et seulement 30 % à des erreurs de code. Pourtant, les DSI responsables de diverses cultures informatiques d’aujourd’hui manquent de visibilité et de contrôle sur le processus de déploiement des logiciels.

Quelles solutions émergent ? Depuis le dernier Gartner Symposium, nous assistons à la convergence des technologies de Release Management et DevOpsEnterprise DevOps arrive à maturité.

En tant que mouvement dominant, la communauté DevOps assume la responsabilité opérationnelle synonyme de succès.  L’agilité du « Dev » confronte les contraintes et les politiques d’entreprise familières aux « Ops ».

Du CI/CD vers l’Entreprise DevOps

Les environnements informatiques d’aujourd’hui se composent d’un mélange complexe d’applications composées chacune de centaines de micro services, de conteneurs et de multiples technologies de développement – y compris des plates-formes existantes qui se sont avérées si fiables et précieuses pour l’entreprise que même en 2018, elles constituent toujours le cœur de nombreuses applications commerciales parmi les plus importantes au monde.

De nombreux pipelines CI/CD ont été efficaces en matière d’approvisionnement, de configuration de l’environnement et d’automatisation du déploiement des applications. Mais jusqu’à présent, ils n’ont pas réussi à donner au niveau de l’entreprise les réponses aux questions qu’elle se pose sur la conformité aux réglementations, la gouvernance et la sécurité.

Ce qu’on appelle aujourd’hui les pipelines DevOps sont souvent des chaînes d’outils disparates, fragiles et sur mesure. Conçus principalement pour les environnements natifs du Cloud, ils ont automatisé avec succès un processus reproductible pour faire fonctionner, tester et livrer les applications.

Mais la plupart n’ont pas la couche technologique nécessaire pour gérer les plates-formes héritées comme IBM i (aka iSeries, AS/400) et mainframe z/OS, laissant un « maillon faible » dans le processus de livraison. Cette approche en silo de l’outillage DevOps comporte le risque perpétuel d’arrêts de production et de coûts incontrôlés.

Des solutions émergent. Écoutez l’expérience de SpareBank1 comme exemple récent. La prochaine phase de la gestion des versions est déjà en place. Enterprise DevOps offre un pipeline de livraison de logiciels unique et commun à travers toutes les cultures de développement informatique et une transparence de bout en bout sur l’état des versions.  Ce blog explique comment nous en sommes arrivés là.

Qu’est-ce qui retient DevOps ? Le bimodal IT détient la clé

Ces dernières années ont vu l’émergence du « Bimodal IT« , une pratique de gestion informatique qui reconnaît deux types – et deux vitesses – de développement logiciel et prescrit des processus distincts mais coordonnés pour chacun.

Gartner Research définit le Bimodal IT comme  » la pratique consistant à gérer deux styles de travail distincts mais cohérents : l’un axé sur la prédictibilité et l’autre sur l’exploration « .

Dans la pratique, cela nécessite deux voies parallèles, l’une soutenant le développement rapide d’applications pour les projets d’innovation numérique, et l’autre, plus lente, pour la maintenance continue des applications sur les principaux actifs logiciels.

Bimodal IT

Selon Gartner, les styles de travail en IT se répartissent en deux modes. Le mode bimodal 1 est optimisé pour des domaines plus prévisibles et mieux compris. Il met l’accent sur l’exploitation de ce qui est connu, tout en transformant l’environnement existant en un état qui convient à un monde numérique. Le mode 2 est exploratoire, expérimental pour résoudre de nouveaux problèmes et optimisé pour les zones de flous. Ces initiatives commencent souvent par une hypothèse qui est testée et adaptée au cours d’un processus impliquant de courtes itérations, adoptant potentiellement une approche de produit minimum viable (MVP). Les deux modes sont essentiels dans une entreprise pour créer une valeur substantielle et entraîner des changements organisationnels importants, et ni l’un ni l’autre ne sont statiques. Combiner une évolution plus prévisible des produits et des technologies (mode 1) à une nouvelle et plus innovante (mode 2) est l’essence même du modèle bimodal. Tous deux jouent un rôle essentiel dans la transformation numérique.

Les systèmes Legacy comme IBM i et z/OS entrent souvent dans la catégorie Mode 1. Les nouveaux développements sur Windows, Unix et Linux tombent généralement dans le mode 2.

Les limites du CI/CD

Une livraison fluide des logiciels est l’un des principaux objectifs de l’entreprise. L’industrie IT a fait un bond en avant dans cette direction avec l’adoption généralisée de l’intégration continue automatisée et de la livraison continue (CI/CD). Mais soyons clairs sur ce qu’est le CI/CD et ce qu’il n’est pas.

L’intégration continue (CI) est un ensemble de pratiques de développement qui incitent les équipes à mettre en œuvre de petits changements et à vérifier fréquemment le code dans les référentiels partagés. CI commence à la fin de la phase de code et demande aux développeurs d’intégrer du code dans le référentiel plusieurs fois par jour. Chaque contrôle est ensuite vérifié par une build et test automatisés, ce qui permet aux équipes de détecter et de corriger les problèmes rapidement.
La Livraison Continue (CD) prend en charge les phases du SDLC, là où se termine le CI : provision des environnements de test, déploiement des tests, validation des tests et déploiement en production.
Le déploiement continu prolonge la livraison continue : chaque changement qui réussit les tests automatisés est automatiquement déployé en production. Selon DevOps, le déploiement continu devrait être l’objectif de la plupart des entreprises qui ne sont pas contraintes par des exigences réglementaires ou autres.
Le problème est que la plupart des pipelines CI/CD sont limités dans leur utilisation du  » cloud-native « , également appelées nouvelles technologies de l’entreprise. Les entreprises d’aujourd’hui attendent la prochaine évolution, celle d’un pipeline commun et partagé à travers toutes les cultures technologiques. Pour y parvenir, de nombreuses organisations devront passer d’une simple automatisation à de la business release coordination, ou orchestration.

DevOps facts & Predictions Infographic

DevOps – Faits & Prédictions

Infographie

L’adoption de DevOps se développe plus rapidement que jamais. Découvrez quelles sont les dernières prévisions DevOps et comment cette culture agile d’entreprise améliore l’efficacité dans tous les secteurs d’activité !

Découvrez l’infographie

De l’automatisation des versions d’application (ARA) à l’orchestration (ARO)

L’automatisation des versions d’applications (ARA) implique le conditionnement et le déploiement d’une application, d’une mise à jour ou d’une version depuis le développement, dans divers environnements et même jusqu’en production. Les outils ARA associent des fonctionnalités d’automatisation du déploiement, de gestion de l’environnement et de modélisation.
D’ici 2020, Gartner prévoit que plus de 50 % des entreprises mondiales auront mis en œuvre au moins une solution d’Application Release Automation, contre moins de 15 % en 2017. Depuis sa création il y a environ sept ans, le marché des solutions ARA a atteint 228,2 millions de dollars en 2016, en hausse de 31,4 % par rapport à 2015. Le marché devrait continuer de croître à un taux de croissance annuel composé (TCAC) estimé à 20 % jusqu’en 2020.
Le marché de l’ARA évolue rapidement en réponse aux exigences croissantes des entreprises qui souhaitent à la fois étendre les initiatives DevOps et améliorer l’agilité du release management dans de multiples cultures, processus et générations de technologies. Nous voyons ARA se transformer en une nouvelle discipline, l’ Application Release Orchestration (ARO).
Une couche au-dessus d’ARA, les outils ARO (Application Release Orchestration) organisent et coordonnent les tâches automatisées en un flux de travail consolidé de release management. Ils améliorent les meilleures pratiques en déplaçant les artefacts, les applications, les configurations et même les données liées aux applications tout au long du processus du cycle de vie des applications. ARO couvre l’ensemble du processus de livraison logicielle et fournit une visibilité sur l’ensemble du processus de déploiement du logiciel.
ARO est la pierre angulaire d’ Enterprise DevOps.

Enterprise DevOps : concilier qualité et rapidité des déploiements

Enterprise DevOps est encore récent et des définitions divergentes émergent. Considérez-le comme DevOps at Scale.
Tout comme pour le bimodal IT, les grandes entreprises ont recours aux équipes DevOps pour construire et déployer des logiciels via des pipelines individuels et parallèles. Les pipelines circulent en continu du développement à l’intégration et au déploiement de manière itérative. Chaque pipeline parallèle utilise des chaînes d’approvisionnement pour automatiser ou orchestrer les phases et sous-phases du SDLC Enterprise DevOps.
A un certain niveau, les phases du SDLC Enterprise DevOps peuvent être résumées de cette manière : planification, analyse, design, code, commit, test unitaire, test d’intégration, test fonctionnel, test de déploiement, test d’acceptation, déploiement en production, implémentation et feed-back utilisateur.
Les étapes et les tâches de l’ED-SDLC peuvent différer en fonction des pipelines où il peut y avoir un niveau d’importance différent pour chaque étape ou sous-étape. Par exemple, en mode bimodal 1 sur un SOR, les phases de planification, d’analyse et de conception peuvent être plus importantes qu’en mode bimodal 2. Dans le mode bimodal 2 sur un SOE, la fréquence du commit, du test unitaire, du test d’intégration et du test fonctionnel peut être bien plus élevée.
Le risque d’erreur de déploiement est élevé dans les environnements d’entreprise parce que les chaînes d’approvisionnement dans chaque pipeline diffèrent et qu’il existe des dépendances entre les artefacts dans différents pipelines. L’orchestration est nécessaire pour coordonner les processus à travers les pipelines. L’orchestration équivaut à une automatisation plus sophistiquée, avec de l’intelligence intégrée et l’objectif ultime d’être autonome.

Comment faire la transition des systèmes Legacy vers DevOps ?

En réponse aux défis du Bimodal IT, nous avons atteint un point de convergence entre les pratiques classiques du DevOps et du Release Management.
Depuis plus de 25 ans, Arcad Software permet aux grandes entreprises et aux PME d’améliorer le développement de logiciels grâce à des outils uniques et des techniques innovantes. Au cours de cette période, nous avons développé une expertise unique des systèmes IBM i et z/OS existants. Aujourd’hui, nous sommes reconnus par Gartner Research comme un acteur important dans le domaine de l’Enterprise DevOps et de l’ARO, tant pour les plateformes Legacy que modernes.
De nombreux fournisseurs d’ARO s’attendent à de nouveaux développements sur Windows, Unix et Linux et, par conséquent,que les systèmes legacy ne seront plus qu’un lointain souvenir. ARCAD est différent ; nous comprenons la nécessité de tirer le meilleur parti de l’investissement de votre entreprise effectué dans les systèmes legacy au cours des dernières décennies, ainsi que les exigences et les défis liés à la valorisation de ces applications legacy.

ARCAD peut s’assurer que vous pouvez offrir à vos responsables d’applications et parties prenantes une solution pratique et intégrée, étape par étape, pour fournir à la fois DevOps et ARO pour les applications nouvelles et legacy, plutôt que des projets coûteux et risqués de remplacement de l’infrastructure.

Tirer parti des pipelines CI/CD existants

Les organisations disposent aujourd’hui d’un grand nombre d’outils pour mettre en œuvre DevOps. Les outils se superposent et le danger est « l’étalement de la chaîne d’outils ». Pourtant, aucun outil ne peut à lui seul répondre à tous les besoins dans un environnement de développement moderne. Il est donc essentiel que tous les outils sélectionnés s’intègrent facilement les uns aux autres.
La solution ARCAD pour DevOps a une architecture ouverte et s’intègre facilement aux outils standards tels que Git, Jenkins, JIRA, ServiceNow. Elle est capable d’orchestrer la livraison de tous les actifs applicatifs de l’entreprise, depuis les technologies Cloud les plus récentes jusqu’au code de base qui sous-tend votre entreprise.

Les solutions ARCAD étendent et adaptent votre pipeline DevOps existant en un flux de travail sans friction qui supporte TOUTES les plateformes de votre business.

Moderniser votre capital IT

Si l’avenir des applications legacy vous préoccupe, les solutions complémentaires d’ARCAD peuvent automatiser la modernisation de vos bases de données et de votre code legacy – en augmentant leur flexibilité dans les architectures informatiques modernes et en facilitant l’embauche de jeunes développeurs de talent, et en garantissant que les nouveaux recrutés pourront travailler efficacement en équipe avec les membres expérimentés de votre équipe.

Avec 25 ans d’expérience dans le Release Management et de collaboration avec les équipes legacy et Digital IT les plus importantes et les plus respectées à travers le monde, ARCAD Software a intégré la sécurité, la conformité et la réduction des risques dans toutes ses offres. C’est exactement ce vers quoi DevOps se dirige.

(*) Source: IDC

White Paper Enterprise DevOps

Enterprise DevOps White Paper

Cet document a pour objectif de démystifier les différents concepts, terminologies et mythes de DevOps afin de clarifier la marche à suivre.

Télécharger le White Paper

Arcad for DevOps : SpareBank1

Témoignage client SpareBank1 ARCAD for DevOps

SpareBank1 accélère ses cycles de développement sur IBM i, réduisant les coûts de gestion de l’environnement et de conformité de 70%.

Lire le témoignage client

Olenka Van Schendel

Olenka Van Schendel

VP Strategic Marketing & Business Development

Avec 28 ans d’expérience dans les systèmes distribués et IBM i, Olenka a débuté dans le domaine de l’intelligence artificielle et du traitement du langage naturel, en travaillant comme ingénieur logiciel, principalement sous UNIX. Elle s’est rapidement spécialisée dans le développement d’outils logiciels intégrés comprenant des compilers, des débuggers et des systèmes de gestion du code source. En tant que VP Business Development au sein du groupe ARCAD Software, elle continue à se consacrer à la gestion du cycle de vie des applications (ALM) et à l’outillage DevOps dans une perspective multiplateforme, notamment IBM i.

2019-01-10T16:50:09+00:00 Blog|

Quelles évolutions pour le DevOps ?

par Marc Dallas | 12 octobre 2018

Le concept DevOps s’est largement développé ces dernières années dans de nombreuses organisations souhaitant répondre plus efficacement à leurs enjeux business.
Si DevOps concernait jusque-là principalement les services IT, il se répand aujourd’hui sur l’ensemble de la chaîne de l’entreprise et entraîne de nombreuses évolutions.

DevOps, avant tout une gestion du changement

Les organisations qui ont mis en place tout ou partie de DevOps ont depuis longtemps identifié et validé qu’une telle démarche garantissait un retour sur investissement.
Par contre, beaucoup d’autres ont abordé et étudié DevOps mais ne l’ont pas encore traduit dans les faits.
La raison principale est que DevOps est avant tout une démarche de gestion du changement.
En effet, DevOps ne se résume pas à choisir la bonne solution d’automatisation. Il est surtout important de se faire accompagner dans cette démarche, et c’est de la responsabilité d’un éditeur. Dans un projet DevOps, les niveaux de maturité et de compréhension sont différents suivant les organisations. Un fournisseur de solutions DevOps a donc un devoir de conseil et d’accompagnement dans la gestion du changement et doit apporter de la valeur. Il doit également prendre en compte l’entreprise dans sa particularité, sa diversité. Dans le cas contraire, un projet DevOps n’a aucune chance d’aboutir.

L’apparition de DevSecOps et BizOps

L’apparition de ces termes est directement liée à la difficulté de la relation entre le développement et l’opérationnel.
A l’époque, le développement s’était organisé avec l’arrivée de méthodes agiles, alors que l’opérationnel représentait un goulot d’étranglement. Pour que le cycle soit fluide, il fallait donc absolument intégrer les opérations.
Une communication s’est alors créée, et une reconnaissance des contraintes entre les différents services a été mise en place. Nous sommes passés dans une posture de dialogue, d’échanges et d’élaboration des processus : reconnaissance du métier de l’autre et intégration des contraintes de chacun pour pouvoir avoir une zone de discussion commune.

L’apparition de nouveaux termes relatifs au DevOps représente simplement une extension de la posture de communication à l’ensemble des services, une progression dans la mutation des entreprises.
Le DevSecOps, par exemple, a pour objectif de renforcer la sécurité en l’intégrant dès le début du processus de développement des applications. D’autres services pourraient d’ailleurs être rajoutés dans la chaîne.
Cela veut surtout dire qu’aujourd’hui les entreprises prennent conscience qu’il y a une nécessité d’avoir une chaîne logistique globale qui, à chaque articulation, intègre la même posture que celle décrite par DevOps.

BizOps est davantage un terme générique. Il s’agit d’une chaîne entre le business et l’opérationnel. C’est une contraction que l’on pourrait finalement appeler « BizDevSecOps ».
Elle implique la direction stratégique à l’opérationnel. Nous devrions d’ailleurs ne plus parler d’Ops aujourd’hui, mais d’utilisateurs (BizUsers).
Nous revenons finalement à de vieilles notions telles que le BtoB ou le BtoC, excepté le fait que l’on intègre aujourd’hui à la connotation de ces termes un changement d’organisation interne, nécessaire à l’entreprise. Cela permet d’obtenir une granularité de travail pour pouvoir se concentrer sur la résolution de problèmes dans un domaine particulier. Il s’agit de définir et d’exécuter toutes les actions requises et les automatiser dans un environnement de livraison continue.
C’est toute la notion de Release Coordination, de la direction stratégique jusqu’à la mise à disposition auprès de l’utilisateur.

Multi-Platform & Open Source Development Tools in a Traditional IBM i Environment White Paper

DevOps – Faits & Prédictions

Infographie

L’adoption de DevOps se développe plus rapidement que jamais. Découvrez quelles sont les dernières prévisions DevOps et comment cette culture agile d’entreprise améliore l’efficacité dans tous les secteurs d’activité !

Découvrez l’infographie

Les challenges de l’Enterprise DevOps

La notion d’Enterprise DevOps permet de positionner DevOps comme une stratégie d’entreprise, un processus qui apporte de la plus-value à l’organisation, et pas uniquement dans les services informatiques.
Les enjeux en termes d’identification, de validation de release entre les différents services, d’explication d’un goulot d’étranglement, de temps de décision, de réalisation ou temps de mise à disposition, s’ils sont résolus à l’échelle du DevOps, peuvent être un terrain expérimental. Cette notion d’articulation interservices pourra alors être étendue à l’ensemble de l’entreprise, ce qui permettra de facto d’augmenter le retour sur investissement sur la globalité.
Et c’est là tout le défi de l’Enterprise DevOps : que l’ensemble de l’entreprise prenne conscience de la plus-value apportée par ce changement de collaboration entre services.
Tout ce travail géré à l’échelle microscopique entre Dev et Ops sera alors implémenté à une échelle macroscopique au sein de l’ensemble de la chaîne de l’entreprise (de la décision stratégique à l’utilisateur final).

Les enjeux de DevOps for Database

Même si elle n’est pas nouvelle, la notion de donnée prend aujourd’hui de l’ampleur.
Afin de gagner du temps et d’éviter les développements, la notion de paramétrage de données (quelles qu’elles soient et sans présager de la structure technologique de gestion de données sous-jacentes), a été introduite de façon à modifier le comportement de la solution en fonction des données qui ont été saisies.
Ces données de paramétrage ont donc un impact sur le comportement de la solution. A ce titre-là, ces données appartiennent au domaine du développement et du fonctionnement de l’application.

Généralement, le volume de données restant faible, des processus dégradés sont utilisés pour la mise en production.
Ces processus dégradés ne permettent donc pas d’effectuer des rollbacks, ni par exemple d’identifier le niveau de version du système installé, mais tout cela est considéré comme anecdotique puisque le volume de données reste faible.
Pourtant, la criticité est très importante.
En procédant de cette manière, la chaîne de qualité est rompue, et cela peut mener à un incident de production qui engendrera des pertes financières parfois énormes, mais aussi une perte de confiance dans le processus de déploiement.
Il ne faut donc pas se concentrer uniquement sur la fréquence de déploiement, mais aussi sur la criticité de ce que représentent ces données.
Elles doivent donc suivre la même chaîne de qualité que les applications, ce que promet DevOps for Database.

Conclusion

  • DevOps ne se résume pas à l’automatisation des processus, c’est une véritable démarche de gestion du changement
  • Les termes DevSecOps et BizOps signifient que les entreprises prennent conscience qu’il y a une nécessité d’avoir une chaîne logistique globale
  • L’ensemble de l’entreprise doit prendre conscience de la plus-value apportée par un changement de collaboration entre services
  • Les données souvent critiques doivent suivre la même chaîne de qualité que les applications

White Paper « DevOps for IBM i »

DevOps for IBM i White Paper

Vous souhaitez mettre en place une stratégie DevOps sur IBM i ? Ce White Paper est pour vous !

Télécharger le White Paper

Témoignage client Système U

Système U Success story

Système U réduit de 40% le coût de déploiement de ses applications en utilisant DROPS sur IBM i et Linux

Lire le témoignage

Marc Dallas

Marc Dallas

Directeur R&D

Diplômé en Ingénierie Informatique à Integral International Institute, Marc commence sa carrière en 1994 en tant qu’Analyste Programmeur chez Nestle Cereal Partners. Il est ensuite nommé Directeur Produit chez ADSM Software, avant de rejoindre ARCAD Software en 1997.

2018-11-29T10:59:02+00:00 Blog|

5 questions les plus fréquentes sur l’anonymisation des données

par Maurice Marrel | le 13 septembre 2018

Le RGPD, la confidentialité et les réglementations sur la protection des données ont soulevé plus de questions que jamais sur le traitement des données. Nous avons demandé à notre DPO et expert en anonymisation, Maurice Marrel, de répondre à certaines des questions les plus courantes auxquelles nos clients sont confrontés aujourd’hui.

1. Quel est le rôle de l’anonymisation dans le respect du RGPD ?

Ces dernières années, le numérique connecté a considérablement transformé la circulation des données.
Les données de production sont copiées en environnements de test, de recette ou de préproduction. Elles sont donc exposées aux regards de testeurs, recetteurs ou développeurs non habilités sur des machines beaucoup moins protégées que les environnements de production.
De nombreux fichiers sont également partagés avec des partenaires extérieurs, et ne doivent livrer qu’une partie des informations réellement transmises.

Ces données personnelles doivent être protégées des fuites et autres indiscrétions.
De ce fait, les législations ont imposé des règles, comme le RGPD en Europe.

Il devient donc impératif de désensibiliser ces données confidentielles.
Cette désensibilisation doit se faire par transformation de ces données, à l’aide d’algorithmes non réversibles.
Cependant, la donnée doit rester exploitable. Un utilisateur testeur doit voir à l’écran, dans le champ nom de famille, un nom de famille modifié qui ressemble à un nom de famille.
Le domaine doit rester le même : un IBAN/RIB ou un numéro de sécurité sociale doit rester valide et compatible avec les exigences et tolérances des applications afin de pouvoir pratiquer les tests sans se faire rejeter d’emblée.
Ces contraintes doivent rester applicables que ce soit avec le phénomène de redondance des données dans des bases de données héritées et archaïques, ou dans un contexte de système de gestion de bases de données multiples.
C’est ce que permet l’anonymisation des données.

2. Anonymisation & pseudonymisation : en quoi diffèrent-elles ?

L’anonymisation fait en sorte que les données ne puissent pas être récupérées, et ce de manière irréversible, à contrario de la pseudonymisation.

Dans un environnement de test, même si les machines sont sécurisées, ce sont les développeurs, testeurs, recetteurs, personnels en formation qui ont accès directement à la donnée. Il faut donc impérativement anonymiser ou pseudonymiser la donnée en amont.
Dans le cas d’une pseudonymisation, les données peuvent aussi optionnellement être conservées cryptées dans les métadonnées de la solution logicielle, afin de pouvoir être restituées unitairement sur demande aux seules personnes autorisées. Les données anciennes sont dans ce cas conservées. Cela peut être utile par exemple pour vérifier un problème isolé dans un environnement de test.

La pseudonymisation est souvent la seule solution compatible avec un fonctionnement normal des applications et avec l’exhaustivité des scénarios de tests.
C’est en revanche une technique qui présente une certaine réversibilité de par les clefs d’identification qui ne sont pas toujours remplaçables pour des raisons techniques, et de par des données identifiantes, comme des numéros de clients, qui sont parfois le seul lien entre les technologies de stockage de l’information (SGBD, fichiers). La combinaison des données entre elles peut aider des organisations mal intentionnées à statistiquement deviner certaines données d’origine.

3. Données personnelles & données sensibles – quels impacts sur la gestion des données ?

Selon la CNIL, une donnée personnelle est « toute information relative à une personne physique susceptible d’être identifiée, directement ou indirectement ». Tandis qu’une donnée sensible concerne « toute information qui révèle les origines raciales ou ethniques, les opinions politiques, philosophiques ou religieuses, l’appartenance syndicale, la santé ou la vie sexuelle d’une personne physique. »

Mais cette différenciation des données peut prêter à confusion.
Le plus important est de bien identifier les données à anonymiser. L’objectif est d’empêcher toute correspondance entre ces données. On peut par exemple ne pas modifier une donnée de type état de santé si le nom et prénom correspondant est anonymisé.
L’anonymisation concerne donc tous les types de données en exploitant des algorithmes.

4. L’anonymisation impacte-t-elle les performances de mon informatique ?

Il convient de ne pas prendre en compte la performance seule, mais également la sécurité.
Une anonymisation engendre un traitement, et aura donc forcément des impacts sur les performances. Cependant, si elle est bien anticipée et les exigences bien définies, les impacts seront minimisés. De plus, on constate que seuls une vingtaine de pourcents des données nécessitent d’être anonymisées.

De manière générale, lors d’une anonymisation, les données seront directement récupérées depuis un environnement de production pour être insérées dans un environnement de test. Mais même si les utilisateurs (développeurs, testeurs etc.) n’y ont pas accès durant le traitement, les environnements de test sont la plupart du temps bien moins protégés.
La solution idéale, dans ce cas, consistera à effectuer une copie de la base de production. Cela permettra à la première de rester disponible pendant que l’autre se fera anonymiser.
Les données anonymisées seront ensuite diffusées sur les environnements de test, de recettes et de formation concernés.
Une autre solution consiste à isoler une copie des environnements de production en machines de tests tout en limitant l’accès durant l’anonymisation, pour ensuite diffuser sur l’environnement de test.

5. Comment identifier les données qui doivent être anonymisées ?

Généralement, l’anonymisation est réalisée pour les environnements de test.
Une bonne connaissance du périmètre global de la base de données est donc nécessaire, car elle permettra de comprendre quels sont les types de données que l’on aura besoin d’anonymiser.
Il faut également prendre en compte la façon dont les données sont liées entre elles, car certaines sont indissociables.
La découverte en bases de données d’éligibilité des données à anonymiser doit être la plus automatisable possible afin d’assister l’administrateur par des algorithmes dédiés aux divers types de données.

Mais dans certains cas, l’anonymisation devra être réalisée pour les environnements de production, notamment dans le cadre du droit à l’oubli, considérablement renforcé par le RGPD.
En effet, toute personne résidant dans l’Union Européenne et dont une organisation détient des données personnelles pourra avoir le contrôle sur ses données.
Mais dans de nombreux cas, supprimer purement et simplement ces données aurait un impact important sur les autres données. L’anonymisation se présente alors comme la meilleure solution, car elle permet de rendre inaccessible les données personnelles, tout en conservant les données nécessaires au bon fonctionnement des applications et à leur cohérence.
Prenons l’exemple d’un site de commerce en ligne. Lorsqu’un produit est vendu, les données de type sortie de stock, entrée d’argent ou numéro de colis de livraison sont nécessaires au bon fonctionnement de l’entreprise et ne peuvent pas être supprimées. Par contre, le nom de l’acheteur, son adresse ou encore ses données bancaires peuvent l’être.
Le droit à l’oubli, qu’il soit dû à une demande spécifique ou à une réglementation sur la conservation de données anciennes, est donc la principale raison des anonymisations en environnement de production.

Conclusion

  • L’anonymisation répond aux exigences du RGPD car elle permet de transformer des données de manière irréversible, tout en restant exploitables
  • L’anonymisation concerne toutes les données, personnelles ou sensibles, en exploitant des algorithmes
  • Si l’anonymisation est bien anticipée et les exigences bien définies, les impacts sur la performance seront minimisés
  • Une anonymisation peut être nécessaire dans un environnement de production dans le cadre du droit à l’oubli
Protection des données personnelles

Protection des données personnelles

White Paper

Préparez-vous aux enjeux liés au Nouveau Règlement Européen sur les données personnelles (RGPD) !

Télécharger le White Paper
Dot Anonymizer Datasheet

Dot Anonymizer

Datasheet

DOT-Anonymizer vous accompagne pour protéger la confidentialité de vos données de test, cette documentation vous présente son fonctionnement.

Télécharger la Datasheet

Maurice Marrel

Maurice Marrel

Consultant solutions senior, DOT Software

Maurice Marrel dispose de plus de 20 ans d’expérience dans des environnements informatiques multiplateformes et participe activement à la modernisation de projets à la pointe de la technologie.
Aujourd’hui, il s’est spécialisé dans l’avant vente technique et la formation pour ARCAD et DOT Software. Maurice a ainsi développé une forte expertise technique de part ses expériences, comprenant la gestion des services informatiques dans l’industrie aérospatiale, le secteur énergétique et a également assuré la direction de projets dans divers secteurs d’activités, notamment les outils de développements de logiciels.

2018-11-29T19:15:18+00:00 Blog|

Université IBM i : Let’s break the Barriers !

Retour d’expérience sur ma 1ère Université IBM i

par Olivier Bourgeois | le 28 mars 2018

universite-ibm-i

Les 16 et 17 mai derniers, à l’IBM Client Center de Paris, j’ai eu la chance de participer à la 8ème édition de la conférence annuelle dédiée à l’IBM i.

Une Université particulière pour mes grands débuts, puisqu’elle coïncidait aux 30 ans de la solution.

Au programme de ces 2 jours, quelques 56 sessions ont été organisées (autour des thématiques DevOps-Modernisation, DB2-Analytique, IA-Watson, Sécurité-GDPR, Système-Performances, Infra-HW-Stockage et Cloud), ainsi que 2 plénières, avec entre autres 3 sommités IBM Worldwide : Stefanie Chiras (Vice-Présidente des offres IBM Power Systems), Alison Butterill (Directrice des offres IBM i) et Stacy Benfield (Spécialiste des performances IBM i).

Et le moins que l’on puisse dire, c’est que du haut de ses 30 ans, l’IBM i peut compter sur une communauté fidèle et dynamique ! Plus de 600 participants étaient présents durant ces 2 jours, parmi lesquels une nouvelle génération issue des formations IBM Lab Services ou encore du programme IBM « Fresh Faces », une initiation visant à mettre en valeur la prochaine génération d’innovateurs IBM i.

Et ce qui m’a particulièrement frappé durant ces 2 jours, c’est que malgré l’effervescence provoquée par cette Université, on pourrait penser que ces systèmes “Legacy” vieux de 30 ans ne sont pas concernés par la digitalisation des entreprises, mais c’est tout le contraire. Ils sont, entre autres, confrontés à 2 défis majeurs :

Moderniser ces applications critiques pour répondre aux nouveaux enjeux business

Les nouveaux webservices, les interfaces web avec une UX enrichie ou les nouvelles applications mobiles doivent impérativement interagir avec les systèmes centraux.

Pour répondre à l’ampleur sans cesse croissante de ces évolutions, il est donc primordial de les moderniser, tout en maîtrisant les risques d’erreurs sur ces applications critiques qui font tourner le cœur du business de l’entreprise.

Cette transformation digitale impose donc un déploiement continu, rapide, qualitatif et agile.

Fort heureusement, des solutions de stratégies DevOps et d’automatisation de déploiement d’applications permettent de répondre à ce challenge.

Intuitives et simples d’utilisation, ces solutions permettent aux équipes de développement et d’exploitation de travailler en étroite collaboration pour répondre en douceur à des demandes de déploiement de plus en plus fréquentes.

Certaines solutions permettent également un déploiement d’applications sur de multiples plateformes, et proposent une intégration avec des outils externes tels que Git, Jenkins, JIRA et bien d’autres.

Assurer le maintien des applications et la collaboration entre générations

Pour continuer à exister, ces systèmes vont devoir s’adapter aux jeunes générations.

En effet, la grande majorité des équipes ayant évolué sur les premières générations d’IBM i sont sur le point de partir en retraite ou le sont déjà. En parallèle, la jeune génération, elle, ne connaît que les langages SQL ou Java, et elle n’imagine même pas qu’une interface classique 5250 avec un « écran vert » puisse réellement exister.

La modernisation des IBM i devient donc un enjeu stratégique pour les entreprises, afin que quelqu’un puisse continuer à maintenir le code de ces systèmes « Legacy », le plus souvent hautement critiques pour les entreprises.

Et pour cela, cette modernisation doit s’opérer à minima à 2 niveaux :

  • Celui du langage, car pour séduire cette nouvelle génération, et assurer une pérennité des compétences, il faut absolument convertir le RPGLE en Free Format RPG (très proche du .net & Java), beaucoup plus accessible.
  • Celui de l’interface, parce qu’une modernisation est nécessaire afin de les rendre “User Friendly” pour les nouveaux utilisateurs, mais aussi pour développer des applications web et mobiles sans remettre en cause l’existant. Fort heureusement, plusieurs solutions de « Screenscraping » existent, qui permettent une modernisation simple et rapide de l’interface sans rien toucher au code.

Pour poursuivre cette réflexion et trouver des solutions à ces enjeux, je vous invite à continuer votre lecture avec ce livre blanc sur la thématique DevOps for IBM i.

2018-11-29T11:06:14+00:00 Blog|