La situation quand on débarque

Un gros projet de refonte SI dans une banque. Vingt personnes côté dev, un intégrateur, plusieurs équipes métier. Go-Live dans 5 mois. Sur le papier, ça avance.

Dans la vraie vie, c’est le bazar. La recette a démarré depuis 3 semaines et voilà ce qu’on trouve en arrivant :

Ce qu’on a trouvé en arrivant : Les testeurs font ce qu’ils peuvent, chacun à sa sauce. Les anomalies sont remontées par mail, par Teams, parfois sur Post-it collés sur l’écran du développeur. Personne ne sait combien il y a de bugs ouverts. Le Go-Live a déjà été repoussé deux fois.

Le chef de projet m’a dit : « On a une recette qui tourne, tout va bien. » J’ai demandé le taux de réussite des tests. Silence. Personne ne le connaissait.

— Consultant QA, premier jour sur site

⚠ Quand on arrive

  • Anomalies par mail, Teams, Post-it
  • 120 cas de tests en vrac, non priorisés
  • Specs à trous sur les 3 modules critiques
  • Aucun dashboard qualité
  • Go-Live repoussé 2 fois

✓ Quand on part

  • Suivi centralisé, 1 ticket = 1 bug
  • 380 cas de tests structurés par criticité
  • 45 pages de specs complétées / réécrites
  • Dashboard hebdo, KPI clairs
  • Go-Live respecté

Ce qu’on a fait, semaine par semaine

Semaine 1

Inventaire général

On a recensé toutes les anomalies qui traînaient — dans les mails, les Excel, les conversations Teams. 47 bugs retrouvés, éparpillés partout. Certains en double, d’autres déjà corrigés mais personne n’avait mis à jour le statut.

Semaine 2-3

Structuration du plan de tests

380 cas de tests produits, classés par module et par criticité. Chaque cas lié à une exigence fonctionnelle. Si le test passe, on sait que la règle métier est bonne.

Semaine 2-4 (en parallèle)

Reprise des specs fonctionnelles

Côté AMOA : les 3 modules les plus critiques avaient des trous énormes. Genre « qu’est-ce qui se passe si le taux est négatif ? » — personne n’avait formalisé le cas. 45 pages complétées, validées avec le métier.

Mois 2 à 4

Exécution, pilotage, reporting

Déroulé systématique du plan de tests. Comité qualité hebdo de 30 min avec un dashboard simple. Tests de non-régression à chaque correctif.


Les livrables concrets

Voilà à quoi ressemblent nos outils de pilotage. Pas des slides — des vrais fichiers de suivi.

Suivi des anomalies (extrait anonymisé)
IDModuleAnomalieCriticitéStatutResp.
ANO-012Gestion comptesCalcul intérêts KO sur taux négatif Bloquant OuvertMOE - J.D.
ANO-015VirementsIBAN non validé format SEPA Bloquant En coursMOE - S.M.
ANO-018ReportingExport CSV tronqué après 10k lignes Majeur CorrigéMOE - P.L.
ANO-023Gestion comptesLibellé coupé à 30 caractères Mineur CorrigéMOE - J.D.
ANO-031AuthTimeout session 5 min au lieu de 30 Majeur En coursMOE - K.R.
Chaque bug a un ID, un responsable, un statut. Fini le Post-it.
Plan de tests (extrait anonymisé)
Réf.ScénarioCas de testPrioRésultatLien spec
CT-101Ouverture compteCréation PEL avec taux réglementé P1 OKSF-2.3.1
CT-102Ouverture compteRejet si client interdit bancaire P1 OKSF-2.3.4
CT-145Virement SEPAVirement > plafond = alerte P1 KOSF-4.1.2
CT-203ReportingGénération relevé mensuel PDF P2 OKSF-7.2.1
CT-267Clôture compteClôture avec opérations en attente P1 En coursSF-9.1.3
Chaque test est lié à une spec. Quand un test est KO, on sait exactement où regarder.

Notre process qualité en 5 étapes

1
Inventaire

Recenser tous les bugs existants

2
Qualification

Criticité, responsable, délai

3
Plan de tests

Cas structurés, priorisés, liés aux specs

4
Exécution

Déroulé systématique + non-régression

5
Pilotage

Dashboard hebdo, comité qualité

Dashboard qualité hebdomadaire
380
Cas de tests
94%
Exécutés
3
Bloquants ouverts
87%
Taux de réussite
12S1
22S2
34S3
28S4
16S5
8S6
3S7
Anomalies ouvertes par semaine. La courbe descend = on reprend le contrôle.

Avancement de la recette — progression par module

Gestion des comptes 100%
Virements SEPA 92%
Reporting & exports 88%
Authentification & droits 95%
Clôture de comptes 78%

Les résultats

-60%
Anomalies en prod vs. les projets précédents
380/380
Cas de tests exécutés
On time
Pas de 3ème report

Ce qu’on en retient

La recette, c’est pas « tester ». C’est piloter la qualité. Si t’as pas de plan de tests, pas de suivi d’anomalies, pas de rôles clairs, même les meilleurs testeurs du monde ne peuvent rien faire. Le problème n’était pas technique — il était organisationnel.
Les specs à trous, c’est le mal absolu. On ne peut pas recetter ce qui n’est pas spécifié. « Mais c’était évident » — non, c’est jamais évident. Si c’est pas écrit, c’est pas spécifié.