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 :
- Les testeurs font ce qu’ils peuvent, chacun à sa sauce. Certains testent « au feeling », d’autres suivent des specs qui datent de 6 mois.
- Les anomalies sont remontées par mail, par Teams, et oui — parfois sur Post-it collés sur l’écran du développeur.
- Personne ne sait combien il y a de bugs ouverts. Ni lesquels sont bloquants.
- Le Go-Live a déjà été repoussé deux fois. Le sponsor commence à perdre patience.
Le chef de projet MOA est compétent, mais il fait tout en même temps : les specs, la recette, les comités, la relation métier. Il court partout et personne n’a de visibilité sur rien.
Ce qu’on a fait concrètement
On est arrivé à deux. Un profil AMOA pour reprendre les specs, un profil QA (certifié ISTQB) pour structurer la recette. Pas de grande théorie, on a bossé.
Première semaine : on fait l’inventaire
On a recensé toutes les anomalies qui traînaient — dans les mails, les fichiers Excel partagés, les conversations Teams. On en a retrouvé 47, éparpillées partout. Certaines étaient des doublons, d’autres étaient déjà corrigées mais personne n’avait mis à jour le statut. On a tout centralisé dans un seul outil avec des règles simples : une anomalie = un ticket, un niveau de criticité, un responsable.
| ID | Module | Anomalie | Criticité | Statut | Resp. |
|---|---|---|---|---|---|
| ANO-012 | Gestion comptes | Calcul intérêts KO sur taux négatif | Bloquant | Ouvert | MOE - J.D. |
| ANO-015 | Virements | IBAN non validé format SEPA | Bloquant | En cours | MOE - S.M. |
| ANO-018 | Reporting | Export CSV tronqué après 10k lignes | Majeur | Corrigé | MOE - P.L. |
| ANO-023 | Gestion comptes | Libellé opération coupé à 30 caractères | Mineur | Corrigé | MOE - J.D. |
| ANO-031 | Auth | Timeout session à 5 min au lieu de 30 | Majeur | En cours | MOE - K.R. |
Semaine 2-3 : on construit le plan de tests
Il y avait 120 cas de tests, écrits un peu n’importe comment, pas priorisés. On a tout repris. On a produit un plan de tests aligné sur les processus métier : 380 cas, classés par module et par criticité. Chaque cas est lié à une exigence fonctionnelle. Si le test passe, on sait que la règle métier est bonne. Si le test échoue, on sait exactement quelle spec est concernée.
| Réf. | Scénario | Cas de test | Prio | Résultat | Lien spec |
|---|---|---|---|---|---|
| CT-101 | Ouverture compte | Vérifier création compte PEL avec taux réglementé | P1 | OK | SF-2.3.1 |
| CT-102 | Ouverture compte | Rejet si client interdit bancaire | P1 | OK | SF-2.3.4 |
| CT-145 | Virement SEPA | Virement > plafond journalier = alerte | P1 | KO | SF-4.1.2 |
| CT-203 | Reporting | Génération relevé mensuel PDF | P2 | OK | SF-7.2.1 |
| CT-267 | Clôture compte | Clôture avec opérations en attente = blocage | P1 | En cours | SF-9.1.3 |
En parallèle : on rebouche les trous dans les specs
Côté AMOA, on a attaqué les 3 modules les plus critiques. Il manquait des règles de gestion entières — genre « qu’est-ce qui se passe quand le client a un taux négatif ? » Personne n’avait formalisé le cas. Les développeurs avaient bricolé un truc, le métier découvrait le problème en recette. 45 pages de specs complétées ou réécrites, validées avec les équipes métier.
Mois 2-4 : on déroule et on pilote
Exécution systématique du plan de tests. Chaque semaine, un comité qualité de 30 minutes avec un dashboard simple : combien de tests exécutés, combien en succès, combien d’anomalies ouvertes par criticité. La direction avait enfin un tableau de bord lisible au lieu de « ça avance, on gère ».
Le résultat
Ce qu’on en retient (pour de vrai)
La recette, c’est pas « tester ». C’est piloter la qualité. Si t’as pas de plan de tests, pas de suivi des 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.
Et 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é.