Le Cycle de Vie du Développement Logiciel pour les Ingénieurs QA

Le cycle de développement logiciel (SDLC) définit les phases par lesquelles passe tout projet logiciel : planification, exigences, conception, développement, tests, déploiement et maintenance.

Les phases

1. Planification

Le projet est en cours de cadrage. Les exigences s'écrivent. Les budgets et les délais se définissent.

Ce que fait le QA ici : pas grand-chose dans la plupart des équipes. C'est un problème. La meilleure contribution QA en planification, c'est d'identifier tôt les exigences de testabilité. La fonctionnalité a-t-elle besoin de journalisation ? D'un accès à l'environnement de test ? D'une façon de réinitialiser l'état ? Soulever ces questions en planification coûte des heures. Les soulever en développement coûte des jours. Ce que le QA devrait faire : assister aux réunions de planification. Demander "comment saura-t-on que ça fonctionne ?" pour chaque fonctionnalité proposée. Signaler les exigences qui sont floues ou ne peuvent pas être testées.

2. Analyse des exigences

Les exigences se précisent et se détaillent. Les user stories s'écrivent. Les critères d'acceptation se définissent.

Ce que fait le QA ici : revoir les critères d'acceptation pour leur exhaustivité. "L'utilisateur peut se connecter" n'est pas testable. "L'utilisateur avec des identifiants valides est redirigé vers /dashboard en moins de 3 secondes, l'utilisateur avec des identifiants invalides voit l'erreur 'Email ou mot de passe incorrect'" est testable. Ce que le QA devrait faire : rédiger des cas de test pendant que les exigences sont en cours de finalisation, pas après. Soulever les cas limites manquants. Résister aux formulations vagues. C'est là que se fait le travail QA le plus précieux.

3. Conception

L'architecture technique se conçoit. Schéma de base de données. Contrats d'API. Structure des composants. Topologie de déploiement.

Ce que fait le QA ici : revoir la conception pour la testabilité. Le système peut-il être testé en isolation ? Y a-t-il des API testables ou tout passe-t-il par l'interface ? Y a-t-il des hooks de journalisation et d'observabilité ? Existe-t-il un moyen d'injecter des données de test ? Ce que le QA devrait faire : soulever les problèmes de testabilité lors de la revue de conception. "Cette fonctionnalité n'a pas d'API, elle ne peut être testée que via l'interface, ce qui signifie que chaque test sera lent et fragile. Peut-on ajouter un endpoint API ou au moins un moyen de préparer l'état de test ?"

4. Implémentation (développement)

Les développeurs écrivent du code. Les fonctionnalités se construisent.

Ce que fait le QA ici : rédiger des cas de test en parallèle. Configurer les environnements de test. Écrire des tests automatisés pour les fonctionnalités au fur et à mesure qu'elles deviennent disponibles. Signaler les bugs au fur et à mesure qu'on les trouve. Ce que le QA devrait faire : tester les fonctionnalités de façon incrémentale, pas tout d'un coup à la fin. Travailler avec les développeurs pour définir ce que signifie "prêt pour le QA". Envisager le pair testing pour les fonctionnalités complexes.

5. Tests

Les fonctionnalités sont terminées et prêtes pour une vérification systématique.

Ce que fait le QA ici : exécuter des cas de test, lancer l'automatisation, faire des tests exploratoires, vérifier les corrections de bugs, faire des tests de régression sur les zones non modifiées. Ce que le QA devrait faire : maintenir un registre clair des défauts. Communiquer clairement sur les risques ("5 bugs de haute sévérité ouverts, nous recommandons de ne pas releaser avant qu'au moins 3 soient corrigés"). Ne pas se contenter de trouver des bugs, aider à les prioriser et communiquer leur impact.

6. Déploiement

Le produit arrive aux utilisateurs.

Ce que fait le QA ici : smoke testing en production ou en staging après le déploiement. Surveillance des erreurs de production. Validation rapide du chemin critique. Ce que le QA devrait faire : avoir une checklist de validation du déploiement. Savoir quels 5 à 10 tests s'exécutent immédiatement après chaque déploiement pour confirmer que le système est sain. Surveiller les outils de suivi des erreurs dans les heures qui suivent la release.

7. Maintenance

Le produit est en production et se maintient. Corrections de bugs, petites améliorations, optimisations de performances.

Ce que fait le QA ici : tests de régression pour chaque changement, aussi petit soit-il. Maintien de la suite de tests au fil de l'évolution du produit. Ce que le QA devrait faire : mettre à jour les tests quand les fonctionnalités changent. Supprimer les tests pour les fonctionnalités retirées. Ne pas laisser la suite de tests devenir un musée de fonctionnalités que personne n'utilise plus.

Les modèles SDLC

Waterfall

Toutes les phases s'exécutent séquentiellement. Les exigences sont verrouillées avant que la conception commence. La conception est verrouillée avant que le développement commence. Les tests n'ont lieu qu'après la fin du développement.

QA en Waterfall : le QA est une phase en fin de cycle. Ça produit les défauts les plus coûteux, les bugs trouvés tard sont chers à corriger. Presque aucune équipe logicielle moderne n'utilise le Waterfall pur.

Agile (Scrum, Kanban)

Le travail se fait en courtes itérations (sprints). Chaque sprint comprend planification, développement et tests. Les fonctionnalités se livrent de façon incrémentale.

QA en Agile : les tests ont lieu dans le sprint, pas après. Les ingénieurs QA font partie de l'équipe pluridisciplinaire. C'est le modèle dominant en 2026 pour les équipes produit.

DevOps/Livraison continue

Intégration continue et déploiement continu. Les modifications de code déclenchent des tests automatisés et peuvent partir en production plusieurs fois par jour.

QA en DevOps : l'automatisation est indispensable, on ne peut pas vérifier manuellement chaque déploiement. Les ingénieurs QA construisent et maintiennent le pipeline d'automatisation. La focalisation passe de l'exécution manuelle des tests à la stratégie de test et à la qualité de l'automatisation.

Pourquoi les ingénieurs QA doivent connaître ça

Savoir où on se trouve dans le SDLC indique quel type de travail QA est le plus précieux maintenant.

En planification, le QA fait la revue des exigences. En développement, il rédige les cas de test tôt. Après le déploiement : smoke testing. Un ingénieur QA qui sait seulement exécuter des cas de test en phase de test n'est utile que dans une phase sur sept. Un ingénieur QA qui comprend le SDLC complet peut apporter de la valeur à chaque étape.

C'est aussi pourquoi le "shift-left" est devenu la philosophie QA dominante : déplacer les tests plus tôt dans le SDLC, là où c'est moins coûteux et plus impactant.