Le shift-left n’a rien de nouveau : la QA boucle la boucle
Cet article montre que les pratiques « shift-left » modernes n’ont rien de nouveau : elles marquent un retour à l’ingénierie structurée et rigoureuse que pratiquaient autrefois les équipes QA. Il explique comment les besoins métier se traduisent en exigences et en spécifications, pourquoi les bonnes questions comptent davantage que les outils à la mode, et pourquoi de nombreuses équipes agiles peinent non pas à cause de la méthode, mais à cause de la façon dont elle est mise en œuvre.
Le test était autrefois une véritable discipline d’ingénierie. Puis on l’a jugé coûteux, lent et redondant. Les départements QA ont été démantelés.
Est alors arrivé le mouvement dit « shift-left » – un nouveau nom pour des pratiques que de nombreuses équipes QA appliquaient déjà depuis des années.
Mais si, comme moi, vous êtes de la vieille école, vous reconnaîtrez dans ces activités « à gauche » exactement ce que faisaient les équipes QA, simplement avec moins de cérémonial et davantage d’esprit critique. Notre secteur a la manie de redécouvrir de vieilles leçons sous de nouvelles étiquettes, et les mêmes défis ont tendance à réapparaître sous d’autres formes.
Une idée reçue a la vie dure dans le test logiciel : il faudrait des outils dernier cri, des plateformes d’IA ou de lourds frameworks d’automatisation pour mettre au jour des problèmes sérieux. C’est faux. Parfois, un crayon, de l’expérience et la capacité de poser les bonnes questions suffisent.
Prenons cette user story agile classique :
En tant qu’utilisateur, je veux me connecter avec mon nom d’utilisateur et mon mot de passe pour accéder au système.
Cela décrit une intention, mais ce n’est pas une exigence.
Avant de me contredire, demandez-vous :
- Qu’est-ce qui doit être considéré comme une exigence, et qu’est-ce qui relève de la spécification ?
- Qu’est-ce qui doit être vérifié, et qu’est-ce qui devrait être validé ?
Tout commence ici : relier l’intention métier à un comportement du système clair et structuré.
(Il s’agit d’une version simplifiée de ce qu’il faut faire, pour que la lecture reste courte.)
Besoin métier (BN)
Il exprime une intention, pas une mise en œuvre.
| ID | Énoncé |
|---|---|
| BN01 | L’accès au logiciel doit être contrôlé. |
| BN02 | Nous prévoyons 1’200 utilisateurs pour l’année 2026, avec un taux d’utilisation quotidienne de 5 % et une croissance de 12,5 % par an. |
Exigence (REQ)
Elle définit ce que le système doit faire – pas comment.
| ID | Énoncé |
|---|---|
| REQ01 | Le système doit authentifier les utilisateurs avant de leur accorder l’accès. |
Spécification (AUTH, PERF)
Elle décrit comment l’exigence sera satisfaite.
| ID | Énoncé |
|---|---|
| AUTH01 | L’authentification doit s’effectuer via OAuth 2.0. |
| AUTH02 | Le système doit afficher un écran de connexion avec des champs de saisie pour le nom d’utilisateur et le mot de passe. |
| AUTH03 | Le système doit prendre en charge l’authentification à deux facteurs (2FA) par SMS ou TOTP. |
Poser les bonnes questions
Pour valider l’exigence et ses spécifications, nous utilisons un questionnaire fondé sur un modèle imposé. C’est la QA qui l’élabore, afin qu’il soit aligné sur la vision métier de la qualité. Les réponses doivent être documentées et peuvent être « Non applicable », « Risque faible jugé acceptable », « À définir », etc. Le questionnaire couvre plusieurs thèmes :
- Sécurité et complexité
- Accessibilité
- Scénarios « et si… »
- Comportement des fenêtres modales
- Gestion des erreurs et retours à l’utilisateur
- Performance et charge
- Aspects juridiques et conformité
Quelques exemples de questions :
| # | Question |
|---|---|
| Q01 | Quelles règles de mot de passe faut-il imposer ? |
| Q02 | La 2FA doit-elle être obligatoire ou facultative ? |
| Q03 | Que doit-il se passer si le SMS ou le TOTP échoue ? |
| Q04 | L’écran de connexion doit-il être compatible avec les lecteurs d’écran ? |
| Q05 | Quelles normes d’accessibilité faut-il respecter ? |
| Q06 | Que se passe-t-il après trois tentatives de connexion échouées ? |
| Q07 | Que se passe-t-il si le fournisseur OAuth est injoignable ? |
| Q08 | Les utilisateurs doivent-ils être avertis en cas d’activité suspecte ? |
| Q09 | La fenêtre modale doit-elle retenir le focus et pouvoir être fermée ? |
| Q10 | Doit-elle être responsive sur tous les appareils ? |
| Q11 | Quels messages d’erreur faut-il afficher ? |
| Q12 | Les messages d’erreur doivent-ils éviter de révéler des noms d’utilisateur valides ? |
| Q13 | Quel temps de réponse attend-on en pic de charge ? |
| Q14 | Faut-il mettre en place une limitation du débit (rate limiting) ? |
| Q15 | Le consentement de l’utilisateur doit-il être recueilli explicitement avant l’authentification ? |
| Q16 | Les journaux d’authentification doivent-ils être conformes au RGPD ou à d’autres lois ? |
Ces questions suscitent des discussions utiles entre la QA, les développeurs et les parties prenantes métier – avant même qu’un seul cas de test soit exécuté ou qu’une seule ligne de code soit écrite.
Spécifications détaillées (traçables et testables)
Lorsque le travail est bien fait, chaque exigence est reliée à des spécifications détaillées et testables.
En voici un extrait, à titre d’exemple :
Protocole d’authentification
- AUTH01 - Le système doit utiliser OAuth2.0 comme protocole d’authentification
Interface de connexion
- AUTH02 - Le système doit afficher un écran de connexion pour lancer l’authentification
- AUTH03 - L’écran de connexion doit comporter des champs de saisie pour le nom d’utilisateur et le mot de passe
Gestion des identifiants
- AUTH04 - Le système doit vérifier le nom d’utilisateur et le mot de passe saisis auprès du fournisseur d’identité
- AUTH05 - Le système doit refuser l’accès si les identifiants ne sont pas valides
Authentification à deux facteurs (2FA)
- AUTH06 - Le système doit prendre en charge l’authentification à deux facteurs
- AUTH07 - La 2FA doit être disponible par SMS ou TOTP
- AUTH08 - Le système doit permettre aux utilisateurs de choisir leur méthode 2FA préférée
- AUTH09 - Le système doit imposer la 2FA avant d’accorder l’accès, lorsqu’elle est activée
Gestion des erreurs
- AUTH10 - Le système doit informer les utilisateurs des tentatives d’authentification échouées
- AUTH11 - Le système doit prévoir un mécanisme de secours si l’envoi par SMS ou TOTP échoue
Performance et charge
- PERF01 - Le système doit assurer l’authentification d’un maximum de 1’200 utilisateurs enregistrés d’ici fin 2026
- PERF02 - Le système doit absorber un taux d’utilisation active quotidienne de 5 %, soit 60 utilisateurs simultanés en conditions normales
- PERF03 - Le système doit pouvoir évoluer pour suivre une croissance annuelle de 12,5 %, soit environ 1’350 utilisateurs fin 2027 et 1’520 fin 2028
- PERF04 - Sous la charge prévue, le temps de réponse de l’authentification ne doit pas dépasser 2 secondes pour 95 % des tentatives de connexion
- PERF05 - Le système doit garantir une disponibilité de l’authentification de 99,9 %, hors maintenance planifiée
- PERF06 - Le système doit mettre en place une limitation du débit (rate limiting) pour empêcher les abus et garantir une répartition équitable des ressources lors des pics d’utilisation
- PERF07 - Le système doit être testé dans des conditions de pic de charge simulées, afin de valider les seuils de performance et d’identifier les goulets d’étranglement
La traçabilité, un art oublié
Une matrice de traçabilité relie entre eux besoins métier, exigences et spécifications, ce qui montre clairement pourquoi chaque fonctionnalité existe et comment elle sera testée. C’était autrefois la colonne vertébrale d’une ingénierie QA sérieuse, et le mouvement « shift-left » d’aujourd’hui ne fait que revenir à ces principes fondamentaux.
Voilà à quoi ressemblait une ingénierie QA sérieuse.
| ID | Type | Énoncé | Lié à |
|---|---|---|---|
| BN01 | Besoin métier | L’accès au logiciel doit être contrôlé. | REQ01 |
| BN02 | Besoin métier | 1’200 utilisateurs d’ici 2026, 5 % d’utilisation quotidienne, 12,5 % de croissance annuelle. | PERF01–PERF03 |
| REQ01 | Exigence | Le système doit authentifier les utilisateurs avant de leur accorder l’accès. | AUTH01-AUTH11, PERF01-PERF07 |
| AUTH01 | Spécification | L’authentification doit s’effectuer via OAuth2.0. | REQ01 |
| AUTH02 | Spécification | Le système doit afficher un écran de connexion pour lancer l’authentification. | REQ01 |
| AUTH03 | Spécification | L’écran de connexion doit comporter des champs de saisie pour le nom d’utilisateur et le mot de passe. | REQ01 |
| AUTH04 | Spécification | Le système doit vérifier le nom d’utilisateur et le mot de passe saisis. | REQ01 |
| AUTH05 | Spécification | Le système doit refuser l’accès si les identifiants ne sont pas valides. | REQ01 |
| AUTH06 | Spécification | Le système doit prendre en charge l’authentification à deux facteurs. | REQ01 |
| AUTH07 | Spécification | La 2FA doit être disponible par SMS ou TOTP. | REQ01 |
| AUTH08 | Spécification | Le système doit permettre aux utilisateurs de choisir leur méthode 2FA préférée. | REQ01 |
| AUTH09 | Spécification | Le système doit imposer la 2FA avant d’accorder l’accès, lorsqu’elle est activée. | REQ01 |
| AUTH10 | Spécification | Le système doit informer les utilisateurs des tentatives d’authentification échouées. | REQ01 |
| AUTH11 | Spécification | Le système doit prévoir un mécanisme de secours si le SMS ou le TOTP échoue. | REQ01 |
| PerF01 | Spécification | Prendre en charge jusqu’à 1200 utilisateurs enregistrés d’ici fin 2026. | REQ01 |
| PerF02 | Spécification | Absorber 5 % d’utilisation active quotidienne (60 utilisateurs simultanés). | REQ01 |
| PerF03 | Spécification | Suivre une croissance annuelle de 12,5 % (1350 en 2027, 1520 en 2028). | REQ01 |
| PerF04 | Spécification | Temps de réponse de l’authentification inférieur à 2 secondes dans 95 % des cas. | REQ01 |
| PerF05 | Spécification | Garantir 99,9 % de disponibilité. | REQ01 |
| PerF06 | Spécification | Appliquer une limitation du débit lors des pics d’utilisation. | REQ01 |
| PerF07 | Spécification | Simuler des pics de charge pour la validation. | REQ01 |
TL;DR – la QA boucle la boucle
- Le test était autrefois structuré, traçable et critique.
- Les pratiques modernes comme le « shift-left » redécouvrent ce que la QA savait déjà.
- Vous n’avez pas besoin de frameworks complexes – il vous faut de la discipline, de la clarté et de bonnes questions.
- La vraie qualité naît de la compréhension du métier, pas seulement de l’automatisation des tests.
Le mot de la fin
Les nouvelles méthodes de développement logiciel comme Agile, RAD, XP ou FDD (...) ont apporté de nombreuses idées précieuses : un feedback plus rapide, une collaboration plus étroite et l’accent mis sur la livraison continue de valeur. Pourtant, les difficultés surgissent souvent non seulement lors de l’adoption de la méthode elle-même, mais aussi dans la façon dont elle est couramment mise en œuvre. Dans la pratique, des clarifications, des exigences et des considérations de qualité essentielles passent fréquemment à la trappe, quelle que soit la méthodologie.
Chez House of Test, nous vous aidons à garder la maîtrise de votre qualité grâce à notre approche méthodique et rigoureuse.
J’aide les équipes à comprendre comment leurs systèmes se comportent quand la réalité se complique. Je repère les schémas qui échappent aux autres et je les explique simplement. En dehors du travail, je bricole de petits montages électroniques et je remets en état des appareils, surtout parce que j’aime savoir exactement comment et pourquoi les choses tombent en panne.
