« Shift-left » : les pièges et comment les éviter

Les développeurs d’applications jouent un rôle essentiel dans la réussite et la compétitivité des entreprises. Mais la philosophie du « shift left », ou glissement vers la gauche, qui a fini par dominer la réflexion sur DevOps (ou plutôt DevSecOps) a eu pour effet de les surcharger de travail. Ils sont stressés et fatigués d’être blâmés pour chaque problème ou vulnérabilité qui apparaît lors du déploiement des applications dont dépendent les entreprises. 

Dans le contexte actuel, où les développeurs talentueux sont de plus en plus difficiles à trouver, les départs d’employés et la perte de productivité qui résultent de l’épuisement des développeurs sont terriblement coûteux. Heureusement, ce problème peut être résolu.

Qu’est-ce que le « shift left » ?

Autrefois, les développeurs créaient des applications, puis les ingénieurs chargés de l’assurance qualité vérifiaient leur fonctionnalité et leur facilité d’utilisation. Ensuite, les équipes chargées de la sécurité vérifiaient qu’elles ne présentaient pas de vulnérabilités. Ce n’est qu’une fois que tout avait été vérifié que les applications étaient déployées pour une utilisation opérationnelle.

Plus personne ne dispose de ce temps aujourd’hui. Nous avons besoin que ces applications soient opérationnelles sans attendre ! La solution était, et est toujours, le « shift left », qui consiste à déplacer l’assurance qualité et la sécurité vers la gauche dans le cycle (autrefois) linéaire de développement logiciel (SDLC). L’assurance qualité et la sécurité seraient désormais prises en charge dès le développement initial de l’application, voire lors de la phase de conception. 

Théorie et pratique

C’est une bonne idée en principe. Cela signifiait que les ingénieurs chargés de l’assurance qualité, les experts en sécurité et les développeurs travailleraient ensemble tout au long du SDLC, collaborant en temps réel pour accélérer considérablement le processus et déployer les applications plus rapidement.

Dans la pratique, cependant, cette approche signifie trop souvent que les équipes de développement sont tenues responsables de choses qui ne relèvent pas de leur domaine d’expertise. Par ailleurs, il est plus difficile que prévu d’atteindre ce niveau de collaboration en raison de questions culturelles, et les développeurs se sont dans de nombreux cas vu confier des tâches d’assurance qualité et de sécurité qui n’étaient pas prévues dans leur fiche de poste. 

Bien sûr, il n’y a rien de mal à demander aux développeurs de réfléchir sérieusement à la sécurité dès le départ. S’ils peuvent identifier une vulnérabilité potentielle dans la phase de conception, elle peut être corrigée facilement. En revanche, si le problème n’est découvert qu’après que l’application a été codée et compilée, la correction risque de prendre beaucoup plus de temps, surtout si le code vulnérable comporte également des dépendances. 

Comme l’explique Shannon McFarland dans cet article de blog de Cisco, les avantages escomptés du « shift-left » sont importants : 

1. Amélioration de la collaboration, car les équipes d’assurance qualité, de sécurité et de développement travaillent ensemble et améliorent leur compréhension de l’ensemble du processus SDLC
2. Réduction des coûts grâce à l’identification et à la résolution des problèmes plus tôt dans le processus, d’où des résolutions plus rapides et plus faciles
3. Renforcement de la sécurité, car les développeurs apprennent à intégrer la sécurité dans le processus de conception
4. Amélioration de la qualité des logiciels, car moins de problèmes de qualité sont susceptibles de survivre au déploiement opérationnel

Mais dans la réalité, le « shift-left » entraîne plutôt ces inconvénients :

1. Augmentation de la charge de travail, car les développeurs assument de nouvelles tâches pour lesquelles ils ne sont pas formés, sans réduction de leur charge de travail existante
2. Apprentissage continu nécessaire pour les développeurs, qui doivent maîtriser en permanence de nouveaux outils, processus et technologies, car de plus en plus d’éléments sont déplacés au plus proche des étapes du cycle de développement
3. Burnout, car les développeurs sont soumis à une pression croissante pour créer des applications sécurisées et de haute qualité encore plus rapidement qu’auparavant
4. Perturbation de la dynamique d’équipe en raison de l’effacement des frontières organisationnelles traditionnelles 

Du linéaire au continu

Comme le soutient Melinda Marks dans cet article de TechTarget, le problème avec le « shift-left » tient en partie au fait qu’il repose sur une compréhension linéaire traditionnelle du SDLC, alors que les processus de développement actuels basés sur le cloud sont dominés par des pipelines CI/CD (intégration/distribution continue). 

Pour le dire de manière très simple, cela signifie que de nouvelles fonctions et fonctionnalités (de nouvelles branches d’une base de code en constante croissance) sont continuellement développées, déployées et intégrées dans les applications existantes. Il n’y a pas de moment où l’application est terminée, estampillée « APPROUVÉE » par les équipes d’assurance qualité et de sécurité, et déployée. Les applications critiques pour les entreprises sont en constante évolution.

Il est donc beaucoup plus difficile de pointer du doigt un point dans un processus linéaire et de dire « maintenant, nous allons procéder à l’assurance qualité ici, au lieu de plus tard ». Et cela signifie que les développeurs, les ingénieurs d’assurance qualité et les spécialistes de la sécurité exercent tous leur métier en même temps, dans une boucle continue d’innovation et d’amélioration.

Faire fonctionner le système

Un leadership, des responsabilités clairement définies, une culture dans laquelle on ne porte pas d’accusations et l’adhésion de toutes les parties prenantes sont les clés d’une stratégie « shift-left » réussie qui permet d’obtenir les avantages sans les inconvénients de l’épuisement des développeurs et des coûts que cela implique.

Cela nécessite des compétences organisationnelles solides, comme la capacité à concevoir un processus qui délimite spécifiquement les responsabilités de chaque équipe, plutôt que de se contenter de dire que les développeurs doivent effectuer davantage de tests d’assurance qualité et d’audits de sécurité. Et cela nécessite de nombreuses compétences non techniques en matière de leadership, car il est nécessaire d’encourager toutes les parties prenantes à participer à des analyses rétrospectives sans porter d’accusations, d’apprendre à chacun à accepter et à formuler des critiques constructives avec bienveillance, et de gérer l’intégration et la collaboration d’équipes qui ont traditionnellement fonctionné en silos.