Comment l'approche Shift-Left a amélioré la qualité de nos produits ?

Introduction

Il est 17 h 47. La mise en production vient de se terminer lorsqu’un utilisateur signale une incohérence dans ses données de consommation d’énergie. 

Les vérifications commencent. Les équipes examinent les données, les traitements et les logs jusqu’à identifier l’origine du problème. Le bug n’est pourtant pas apparu lors de la mise en production. Il était présent depuis plusieurs semaines, derrière une spécification trop abstraite dont l’ambiguïté n’avait pas été relevée. 

C’est précisément ce type de scénario que le Shift-Left nous aide à éviter chez Datanumia. 

L’enjeu n’est pas seulement de détecter plus tôt une erreur dans le code. Il s’agit aussi de questionner le besoin avant le développement, lorsque les règles fonctionnelles peuvent encore être précisées et les risques identifiés.

La qualité d’un produit ne se joue pas uniquement lors des tests qui précèdent sa mise en production. Une ambiguïté dans une spécification, une règle métier mal interprétée ou un défaut dans le code peuvent être identifiés bien plus tôt dans le cycle de développement. 

Qu’est-ce que l’approche Shift-Left ?

Dans un cycle de développement logiciel, les premières étapes se situent traditionnellement à gauche : expression du besoin, conception et spécifications. Le développement, les tests finaux et la mise en production arrivent ensuite, vers la droite. Historiquement, une grande partie des tests intervenait à la fin de ce cycle, lorsque le produit était déjà largement développé. 

L’approche Shift-Left déplace une partie de ces vérifications vers l’amont. Avec le Shift-Left Testing, les équipes réfléchissent aux tests dès les premières discussions autour d’une fonctionnalité. Elles cherchent à identifier les ambiguïtés, les risques et les erreurs avant qu’ils ne se retrouvent dans le code. 

Intégrer les tests dès les premières étapes du développement 

Le test Shift-Left ne consiste pas à déplacer à l’identique une campagne de tests finale vers le début du projet. Il intervient à plusieurs niveaux du cycle : clarification des spécifications, définition de critères d’acceptation testables, identification des risques et préparation des tests automatisés. 

Une fois le développement engagé, cette logique se poursuit avec différents niveaux de test. Les tests unitaires et composants vérifient des parties ciblées du code. Les tests d’intégration contrôlent les interactions entre plusieurs composants. Des tests d’API ou d’interface utilisateur complètent ces contrôles selon la fonctionnalité concernée.

Le test devient ainsi un élément du processus de développement, et non une étape isolée avant la mise en production. 

Détecter un défaut lorsqu’il est encore simple à traiter 

Plus un problème est identifié tard, plus son analyse risque de mobiliser de personnes et de concerner plusieurs composants. Une règle métier mal comprise au moment de la conception peut, par exemple, être traduite dans le code, intégrée à d’autres fonctionnalités puis découverte lors des tests finaux. La correction intervient alors sur un produit déjà avancé. 

Le Shift-Left cherche à raccourcir cette chaîne. Une exigence ambiguë peut être questionnée avant le développement. Une erreur dans le code peut être détectée par un test automatisé avant son intégration. Un défaut entre deux composants peut apparaître lors d’un test d’intégration plutôt qu’en phase finale. 

Le développeur obtient aussi un retour plus rapide. Le changement à l’origine du problème est encore récent, ce qui facilite son analyse et sa correction. 

Faire de la qualité une préoccupation continue 

L’approche Shift-Left ne signifie pas que tous les tests doivent être exécutés au début du cycle. Certaines vérifications nécessitent une application intégrée, un environnement représentatif ou une version suffisamment aboutie du produit. Les contrôles réalisés plus tard conservent donc leur rôle. 

La différence tient surtout au moment où la qualité logicielle entre dans le processus. Elle n’attend plus une phase finale dédiée. Les équipes métier, les développeurs et les QA confrontent plus tôt leurs attentes, leurs contraintes et leurs critères de validation. 

Pour répéter certains contrôles au fil des changements de code, cette organisation s’appuie aussi sur l’automatisation. C’est à ce niveau que le Shift-Left rejoint les pratiques DevOps et les pipelines d’intégration et de déploiement continus.

Chez Datanumia, la qualité commence avant le développement

Chez Datanumia, l’approche Shift-Left s’inscrit dans nos pratiques Agile et DevOps. Elle intervient de la préparation des développements jusqu’au delivery, avec un objectif concret : détecter les problèmes plus tôt et éviter de concentrer les contrôles sur les dernières étapes du cycle. 

Le QA intervient dès la préparation du Program Increment 

SAFe organise le travail de plusieurs équipes agiles autour d’objectifs communs. Chez Datanumia, cette organisation repose sur des Program Increments (PI) de cinq sprints. Chaque PI donne aux équipes une visibilité sur les fonctionnalités à développer et les objectifs à atteindre pendant cette période. 

Le rôle du QA ne commence pas une fois ces fonctionnalités développées. Il intervient dès la préparation du PI et pendant les phases de refinement, en cohérence avec notre workflow produit et notre démarche API-First. 

Cette analyse sert aussi à anticiper les tests nécessaires. Une règle imprécise, un cas particulier non traité ou une dépendance mal identifiée peuvent être discutés avant le développement. Le test sert alors à questionner le besoin, et pas seulement à contrôler le résultat final. 

Clarifier le besoin avec les 3 Amigos et l’Example Mapping 

Cette collaboration prend notamment la forme d’ateliers 3 Amigos, qui réunissent les regards métier, développement et QA autour d’une même fonctionnalité. Le métier précise le comportement attendu, le développement examine sa traduction technique et le QA définit les conditions nécessaires à sa validation. 

L’Example Mapping structure ces échanges à partir de règles, d’exemples concrets et de questions. Une exigence générale est confrontée à plusieurs situations pour préciser le comportement attendu du produit. Les zones d’incertitude apparaissent ainsi avant le début du développement. 

Ces échanges aboutissent à des critères d’acceptation testables et partagés par l’équipe. Le développeur connaît le comportement attendu. Le QA dispose des éléments nécessaires pour préparer les tests. Le métier vérifie que les cas retenus correspondent au besoin. 

Chez Datanumia, le Shift-Left repose donc d’abord sur ce travail collectif. La qualité ne commence pas avec l’exécution d’un test, mais lorsque l’équipe partage une compréhension suffisamment précise de ce qu’elle doit développer.

Du développement au delivery : tester tout au long du Program Increment

Une fois le besoin clarifié et les critères d’acceptation définis, le Shift-Left se poursuit pendant le développement. Chez Datanumia, les tests sont répartis au fil des cinq sprints du Program Increment plutôt que concentrés dans une phase de validation finale. 

Automatiser les tests en parallèle du développement 

Lorsque le périmètre fonctionnel est suffisamment stabilisé, la préparation des tests automatisés peut commencer en parallèle du développement. Les critères d’acceptation définis en amont donnent aux équipes une base commune pour construire les scénarios à vérifier. 

Ces tests rejoignent progressivement les pipelines CI/CD. Ils sont exécutés régulièrement au fil des changements apportés au code. Lorsqu’un test échoue, le développement concerné est encore récent. L’équipe peut rechercher l’origine du problème sans attendre la fin du sprint ou du Program Increment. 

Cette organisation ne vise pas à tout automatiser. Le choix dépend du type de fonctionnalité, des risques identifiés et de l’intérêt à répéter le même contrôle. L’automatisation intervient là où elle apporte un retour rapide et exploitable aux équipes. 

Suivre la qualité à chaque sprint 

À chaque sprint, les résultats des tests renseignent les équipes sur la qualité des fonctionnalités développées et sur l’avancement vers les objectifs du Program Increment. Les défauts sont identifiés au fil du développement et peuvent être traités avant les dernières étapes du delivery. 

Cette répartition évite de reporter l’essentiel des validations et des tests de non-régression sur le cinquième sprint. Le dernier sprint ne devient pas une phase de rattrapage où les défauts accumulés doivent être analysés et corrigés avant la mise en production. 

Le Shift-Left s’inscrit ainsi dans le rythme de développement de Datanumia : la qualité est suivie pendant la construction du produit, sans supprimer les contrôles nécessaires avant son déploiement.

Du contrôle final à une responsabilité collective

Chez Datanumia, l’adoption du Shift-Left a changé le moment où la qualité intervient dans le développement de nos produits. Les risques sont examinés dès la préparation du Program Increment, les besoins sont précisés avec les équipes métier, développement et QA, puis les tests accompagnent la réalisation des fonctionnalités au fil des sprints. 

Cette organisation aide à détecter les ambiguïtés et les défauts avant qu’ils ne progressent dans le cycle de développement. L’automatisation apporte un retour régulier sur les changements de code, tandis que le suivi du delivery complète les informations issues des tests. 

La qualité ne repose donc plus sur une validation concentrée avant la mise en production. Elle devient une responsabilité collective, prise en compte de la conception jusqu’au delivery. 

Crédits photo : photo de Compagnons sur Unsplash