Il n'y a pas de phase de test distincte : chaque couche s'exécute lorsque son objet est prêt, et la répétition constitue la recette utilisateur (UAT). La plateforme étant standardisée, les tests portent sur la configuration, les données et les intégrations du client, et non sur la validation du produit lui-même.
| Couche | Quand |
|---|---|
| Vérifications de configuration — chaque paramètre a été vérifié avec des exemples de données dans la session | T-17 → T-11 |
| Validation de la migration — nombres, totaux de hachage, téraoctets et sous-registres par simulation | T-10 → T-3 |
| Tests d'intégration — chaque point de terminaison avec partenaires de test, y compris les chemins d'erreur | T-10 → T-4 |
| Tests de rôles et d'autorisations — chaque rôle voit et fait exactement ce qu'il doit ; SoD | T-9 → T-5 |
| Contrôle de continuité — exercice de basculement si un contrat de Live DR est souscrit ; preuve de sauvegarde et de restauration | T-5 → T-3 |
| La répétition générale = tests d'acceptation utilisateur (UAT) — une véritable journée de travail pour les utilisateurs finaux, en parallèle avec l'environnement existant. | T-2 → T-1 |
Séparation des tâches
Aucun rôle ne peut approuver ses propres créations, créer un fournisseur et le payer, modifier les coordonnées bancaires et effectuer des paiements, ni publier sur des périodes clôturées ou modifier des documents publiés. Chaque rôle doit uniquement voir ses propres entités, données et menus, effectuer toutes les étapes de ses tâches de répétition, consulter les éléments de file d'attente appropriés et utiliser ASK pour ses propres tâches, conformément à ses propres autorisations.
Effectuez le test avec l'identifiant propre à chaque rôle, jamais avec un compte administrateur. Un test réussi en tant qu'administrateur ne prouve rien concernant le rôle.
La répétition
Élaborez le script à partir de la journée type la plus chargée du client, et non d'un flux théorique : la file d'attente du matin, du devis à la commande avec vérification de solvabilité, l'achat, la réception, l'expédition et la facturation, les comptes fournisseurs avec rapprochement et approbation, les opérations de paie, le traitement des paiements et le fichier bancaire, et la clôture de la journée avec la balance de vérification — chaque élément étant comparé à ce que l'ancien système produisait pour la même journée.
- Préparation T-2 — le locataire de répétition à partir des données de l’exécution à blanc ; les documents réels du jour collectés ; chaque utilisateur connecté avec sa file d’attente active ; observateurs par processus.
- Exécution T-1 — les utilisateurs saisissent leur journée réelle dans TRANXACT tandis que le système hérité fonctionne normalement ; ASK et les navigateurs prennent en charge le flux ; les problèmes sont enregistrés avec l'heure et le rôle.
- Clôture du soir T-1 — résultats comparés à la version précédente ; la liste des corrections exécutée et revérifiée ; les critères de passage aux portes ont été évalués ; le propriétaire du compte à rebours décide.
Le choix entre le « aller » et le « ne pas aller » (valeur par défaut proposée)
| Critère | Seuil | Des blocs sont-ils mis en service ? |
|---|---|---|
| Les répétitions ont été validées. | 100 % des éléments critiques ; 95 % ou plus de toutes les étapes | Oui |
| Les résultats correspondent à l'héritage | Totaux égaux ou expliqués | Oui |
| Réconciliation à blanc | Delta zéro TB ; liens entre les sous-registres | Oui |
| Durée de l'essai à blanc | Dans la fenêtre de transition | Oui |
| Défauts critiques ouverts | 0 | Oui |
| Les utilisateurs ont répété leur propre rôle | 95 % ou plus des utilisateurs T+1 | Revoir |
| Intégrations prêtes pour la production | Points de terminaison et informations d'identification confirmés | Examinez la situation si ce n'est pas le cas |
Un refus n'entraîne pas automatiquement un report de date. Le responsable du compte à rebours peut reporter l'échec à T-Plus et lancer la phase de test à T0 avec les éléments validés.
Tri des anomalies, lors de la réunion debout
- Critique — bloque un processus essentiel, entraîne un résultat financier erroné ou une perte de données : corrigez le problème avant la validation finale ou transférez le processus vers T-Plus avec une intervention manuelle intermédiaire.
- Niveau élevé — nécessite un effort considérable : corriger le jour même ; retester lors de la répétition.
- Moyen — une solution simple existe : corriger le problème dans les deux semaines suivant la mise en ligne.
- Bas — cosmétique : une ligne Fit Ledger étiquetée T-Plus.
Lors de la répétition générale chez Calderwood, toutes les étapes critiques sont validées, sauf le traitement du paiement : le fichier bancaire est produit, mais les identifiants de production de la banque n’ont pas encore été émis. Les intégrations non prêtes pour la production sont mises de côté ; le responsable du compte à rebours transmet donc l’intégration bancaire à T-Plus en effectuant un chargement manuel du fichier bancaire à titre provisoire, et l’enregistrement est validé.
Essayez-le À J-1, 91 % des utilisateurs de Calderwood (J+1) ont répété leur rôle. Ce bloc sera-t-il mis en service ?
Pas automatiquement : un taux de répétition inférieur à 95 % est considéré comme un critère d’évaluation, et non comme un obstacle. Les utilisateurs manquants bénéficient d’une séance de rattrapage programmée l’après-midi précédant le jour J, sont signalés dans le registre d’adoption, et ceux qui ne sont toujours pas prêts se voient attribuer un parrain ou une marraine pour leur première semaine.