Sécurité et Agilité en entreprise : contraintes et solutions

Voir la version AMP

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined offset: 0 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 106

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined variable: style in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 149

Notice: Undefined variable: wplinks_image in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 149

Mesures de Sécurité et Agilité entreprise ne font habituellement pas bon ménage. Aussi, il ne faut pas sous-estimer l’impact de la sécurité et de la conformité sur l’Agilité dans le contexte technologique actuel qui appelle de nombreuses entreprises à prendre de telles mesures afin d’assurer l’intégrité de leurs opérations et préserver la confidentialité de leurs données. 

Peu importe le nombre de développeurs dans votre organisation, il est possible de faire du développement logiciel en mode Agile. Des centaines d’écrits vantent les mérites de cette méthodologie de développement; à titre de rappel, en voici les points les plus importants :

  1.       Meilleure adéquation entre les livrables et les besoins ;
  2.       Minimiser le risque de dérapage en découpant le projet en « sprints » et ces derniers en « tâches » de courte durée ;
  3.       Meilleure communication entre les divers intervenants du projet ;
  4.       Emphase mise sur l’identification et la catégorisation des fonctionnalités qui auront le plus de valeur ajoutée pour l’organisation ;
  5.       Dans la trilogie « coût, temps, fonctionnalité », le défi consiste à développer le plus de fonctionnalités parmi les plus importantes dans le temps alloué, quitte à retirer des fonctionnalités, contrairement au mode Waterfall qui met l’emphase sur les fonctionnalités, toutes les fonctionnalités, quitte à dépasser dans le temps.

 

gestion par valeur vs gestion par plan

Le but de ce billet n’est pas de décrire la méthode de développement Agile ou même de tenter de vous convaincre de l’utiliser car la majeure partie des projets TI se font maintenant en mode Agile. Et l’Agilité en Entreprise est devenue réalité pour une large gamme de secteurs d’activités. 

Notre préoccupation est plutôt : que devient l’Agilité en entreprise avec l’intégration de mesures de sécurité et de conformité ?   Sécurité et Agilité peuvent-elles cohabiter entreprise ?   Comment les pratiques et processus Agiles en sont-ils affectés ? 

Décrivons d’abord les impacts que ces nouvelles priorités entraînent :

  1.       Plus d’intervenants et de niveaux d’intervenants impliqués
  2.       Des tests plus rigoureux, plus exigeants
  3.       Des échéanciers de mise en production plus longs
  4.       Coûts de mise en production plus élevés
  5.       Environnement plus complexe
  6.       Une documentation décuplée

 

Clarifions les nouvelles contraintes d’un contexte Sécurité et Agilité en Entreprise :

1.       Plus d’intervenants et de niveaux d’intervenants impliqués

  • Dans un environnement plus contrôlé, le développeur aura peut-être encore la tâche d’écrire les scripts de test mais c’est certain que la responsabilité des tests ne lui incombera pas.  Cette responsabilité sera donnée à l’équipe de « Quality Control » et les tests seront probablement exécuté dans un autre environnement auquel les développeurs n’ont pas accès.
  • De la même manière, les déploiements des versions de test et de production auront été effectués par une autre équipe ou par d’autres usagers.
  • Quant au contenu de la version, l’équipe de déploiement ou même une autre équipe sera responsable de s’assurer que la version de l’application déployée ne contient pas de sous-programme ou d’API qui ne sont pas approuvés par l’équipe responsable de l’environnement logiciel de l’organisation.  Les versions de ces sous-programmes et API doivent être validées.
  • On ne veut pas d’infiltration dans notre environnement.  Une des équipes ci-dessus est aussi responsable de s’assurer que des logiciels robots ont parcouru le code pour s’assurer que celui-ci est de qualité et qu’il est hermétique à toute tentative de hacking du type « injection SQL » ou « injection HTML ».

 

2.       Des tests plus rigoureux, plus exigeants

  • Dans une organisation où la sécurité et la conformité priment, selon le niveau de criticité de l’application, les tests sont les nerfs de la guerre.  Est-ce que vous accepteriez de faire des transactions bancaires avec l’application de votre institution financière si vous aviez seulement l’ombre d’un doute que celle-ci n’est pas intègre ?
  • La plage est grande entre une application de transaction bancaire et une application utilisée par seulement quelques usagers de l’organisation et dont l’impact d’une mise hors service temporaire serait relativement minime.  La qualité et la quantité de tests seront adaptés au niveau de criticité de l’application à mettre en production.

 

3.       Des échéanciers de mise en production plus longs et 4.       Coûts de mise en production plus élevés

  • C’est certain que les deux points précédents ont un impact majeur sur les délais et les coûts de mise en production.
  • En fait, l’impact est si grand que même en conservant des périodes de sprints d’une longueur d’autour de 3 semaines, les mises en production se feront, elles, souvent aux trimestres.
  • Évidemment si on considère le nombre d’intervenants impliqués, le nombre de tests ainsi que le nombre de validations nécessaires à une mise en production, on comprend que le nombre de jours / homme nécessaire sera conséquent… et les coûts aussi !

5.       Environnement plus complexe

  • Les points précédents nous expliquent comment un déploiement en production peut être complexe, combien d’intervenants peuvent être impliqués.  Il faut comprendre qu’un bon nombre d’outils sera aussi nécessaire pour supporter toutes ces opérations. Prenez note que notre objectif n’est pas de publiciser quelques-uns des produits mentionnés ci-dessous, l’objectif est seulement de nommer un produit qui est souvent un leader dans le domaine.
  • D’abord pour les tests, plusieurs intervenants et peut-être plusieurs équipes seront impliqués.  Ça prend donc un outil de communication entre ces intervenants pour énumérer les bugs, les décrire, les suivre, leur assigner un statut, etc.  Dans plusieurs organisations, c’est le produit de Hewlett Packard qui est utilisé, ALM (Application Life Cycle Management). Une firme bien de chez nous qui se spécialise dans la qualité logicielle a aussi développé un bel outil qui intègre l’ensemble des opérations de test dans une seule plateforme; Askida CT.
  • Ci-haut, nous avons indiqué qu’un robot doit parcourir le code pour s’assurer, entre autres, qu’on n’y trouve pas du code permettant des « SQL / HTML injections ».  Selon la taille de l’organisation, ce travail sera donné à l’externe ou sinon, un produit comme Fortify sera utilisé
  • On veut aussi s’assurer que l’application que l’on veut déployer est conforme aux normes et règles de l’organisation.  Le nombre de ces normes et règles peut être faramineux; encore là, ça prend un outil pour nous aider dans cette tâche, un outil comme SD Elements

6.       Beaucoup plus de documentation

  • Conformité et documentation vont de pair.  On ne veut pas d’une organisation « people centric » où l’intelligence d’affaires de l’organisation est dans la tête des gens. On veut une organisation « process centric » où la qualité des processus permettent de croître, de croître rapidement et de façon sécuritaire.
  • Un bon processus est un processus documenté et dont la documentation est à jour

 

Conclusion

Dans ce billet, on comprend que dans un contexte technologique appelant à la cohabitation Sécurité et Agilité en Entreprise, l’impact sur les développements TI principalement, pour une organisation où la sécurité et la conformité priment, peut être important.  Est-ce que ça vaut toujours la peine d’utiliser une méthodologie de développement Agile quand les processus de l’organisation, eux, ne le sont pas ?

À notre avis, oui… mais en s’adaptant aux contraintes de l’organisation et en comprenant qu’il y a un compromis à trouver entre Sécurité et Agilité en entreprise.

Les bénéfices de l’Agilité en Entreprise énumérés au début de ce billet (et dans nos 2 billets précédents) demeurent.  Pour s’adapter aux contraintes d’une organisation orientée « Sécurité & Conformité », je propose d’adopter les directives suivantes :

  • Conserver des longueurs de sprints relativement courts
  • Ajouter un environnement de test qu’on pourrait appeler « TEST PILOTE »
  • Former un groupe pilote avec lequel on travaille plus étroitement et dont l’objectif est de valider que les livrables d’un sprint correspondent aux besoins d’affaires et aux requis
  • Compiler une version à la fin de chaque sprint (ou presque) afin d’être en mesure de faire une démo du sprint à notre groupe pilote et que ceux-ci puissent en commenter les livrables
  • S’assurer de bien gérer les différentes branches de code source car lorsque la machine se mettra en branle pour mettre une version en production, il faudra apporter des corrections et des modifications à du code vieux de plusieurs semaines et il ne faudra donc pas inclure les développements entamés depuis.

Et l’Entreprise Agile devient-elle inaccessible dans un tel contexte de sécurité et conformité ?  Disons que la chemin de l’Agilité en Entreprise sera plus long… beaucoup plus long pour ces entreprises !

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *