Board · Direction & équipe métier
Board — direction et équipe métier
L’application est complète côté mobile. Ce qui reste est de la validation, suspendue à 17 points bloquants côté backend et 7 prérequis côté client.
L'application est fonctionnellement complète côté mobile. Chacun des 48 workflows consomme l'API réelle, les quatre produits du catalogue (Voyage, Scolaire, Accident, Santé) se vendent de bout en bout avec un paiement par carte réellement encaissé, et une campagne de recette automatisée a filmé les 17 parcours. Ce qui reste n'est pas du développement : c'est de la validation, et elle dépend de corrections côté backend et de prérequis côté client.
Flux de données de l'application branchés sur l'API réelle
82 sur 82
Plus aucun écran sur données simulées
Workflows intégrés / hybrides / locaux
35 / 10 / 3
(sur 48)
Produits vendables de bout en bout (devis serveur, contrat créé, paiement encaissé)
4 sur 4
Voyage, Scolaire, Accident, Santé
Tickets bloquants pour la mise en production
17
(13 backend ouverts, 2 contournés, 2 en arbitrage) + 7 prérequis client + 2 correctifs applicatifs
Section 1.1 : État d’avancement global
Progression générale, phases du planning, jalons atteints et à venir, et les points qui attendent une décision.
Progression générale du projet
- Flux de données de l'application branchés sur l'API réellePlus aucun écran sur données simulées
- 82 sur 82
- Workflows intégrés / hybrides / locaux8 hybrides pour une raison backend ou une décision produit, 2 pour un défaut applicatif (inscription, mot de passe oublié) trouvé lors de la recette OTP
- 35 / 10 / 3(sur 48)
- Workflows validables sans action externe9 bloqués par un ticket backend, 1 en attente d'une décision produit, 2 à corriger côté application
- 36 sur 48
- Produits vendables de bout en bout (devis serveur, contrat créé, paiement encaissé)Voyage, Scolaire, Accident, Santé
- 4 sur 4
- Chemins de la spécification réellement consommésLe reste est hors périmètre mobile ou inopérant côté serveur
- 62 sur 94
- Contrôle automatisé du contrat d'APIUne seule dérive, sur un endpoint non branché
- 0 rupturesur un endpoint consommé
- Parcours de recette E2E joués et filmés11 vont au bout (dont l'inscription et le mot de passe oublié, rejoués et filmés code OTP compris avec une boîte jetable), 6 s'arrêtent sur un mur backend
- 17 sur 17
- Tests automatisés au vertTypage strict et lint sans erreur
- 351
- Demandes backend consignées dans l'outil de ticketing39 ouvertes (dont 11 bloquantes), 16 contournées côté application ; un ticket par demande, rattaché à son workflow
- 55du registre + 16 constats d'audit (A9 à A24)
- Tickets bloquants pour la mise en productionListe tenue à part en section 3.0
- 17(13 backend ouverts, 2 contournés, 2 en arbitrage) + 7 prérequis client + 2 correctifs applicatifs
Progression par phase du planning
Les six phases du planning client. La porte de qualité de la phase 3 n’a pas été franchie ; tout le report vient de là.
1 · Setup projet
100 %Initialisation, environnement de dev
2 · Intégration statique
100 %Design system, écrans FR et AR des 5 sprints, livraisons d'APK statiques
Livrée conformément au plan, seule phase entièrement sous contrôle du prestataire
3 · Tests et validation API
Porte de qualité non franchieEnvoi des endpoints par Amana, tests et validation par SHIFTIN, par sprint
Deux lots validés sur six ; Voyage et Compte portent la mention « 3 rounds – toujours pas validé » dans le planning client et n'ont jamais été validés depuis
4 · Intégration API
Câblage terminéBranchement des écrans, gestion des erreurs, livraisons APK internes et client
S1 clos hors corrections du débrief client ; S2 à S5 câblés et testés en réel, validation client suspendue aux tickets backend
5 · Q&A
En coursChecklist, tests finaux, correction des anomalies résiduelles
Campagne E2E exécutée ; passe sur appareil réel et rejeu des deux parcours OTP à faire
6 · Mise en ligne
Non démarréeBuilds release, fiches stores, publication
Comptes Play Store et App Store non fournis
Jalons
Principaux jalons atteints
- Intégralité des écrans statiques livrée pour les 5 sprints, FR et AR, débriefs client pris en charge.
- Quatre produits vendables : devis tarifé par le serveur, contrat réellement créé, paiement par carte encaissé avec émission d'une police, sur les quatre tunnels.
- Authentification réelle : inscription, connexion avec MFA et changement de mot de passe imposé, réinitialisation, empreinte digitale.
- Plus aucun écran sur données simulées : les 14 derniers flux et 4 écrans de contenu ont été branchés lors d'une campagne où chaque endpoint d'écriture a été exercé en réel avant d'être codé.
- Campagne de recette automatisée : 17 parcours Maestro écrits, exécutés contre la pré-production et filmés, avec un carton nommant le ticket backend pour chaque parcours qui s'arrête sur un mur.
- Outil de ticketing livré avec les 55 demandes backend, chacune rattachée à son workflow, et dashboard de reporting en ligne exposant l'APK, les vidéos, les tickets et le planning.
- Outillage de surveillance du contrat d'API (
yarn api:probe,yarn api:contract) qui a permis de qualifier un incident de pré-production en trois minutes.
Jalons à venir · datés en 1.4
- Traitement par Amana des tickets de l'outil de ticketing (lots 1 et 2 en priorité).
- Reprise d'intégration par sprint dès livraison des correctifs, puis APK « ready for client testing » sprint par sprint.
- Rejeu des deux parcours OTP et passe de recette sur appareil réel (caméra, biométrie, paiement, rendu arabe).
- QA final sur l'application complète.
- Version iOS (suspendue au compte App Store).
- Déploiement sur les stores et lancement.
Points d’attention nécessitant une décision ou un arbitrage
Onze points. Les décisions A1 à A6 sont attendues en une seule séance, en ouverture des chantiers (calendrier en 1.4).
| # | Point | Workflow(s) | Pourquoi une décision est nécessaire | Décideur |
|---|---|---|---|---|
| A1 | Authentification par téléphone P0-D#2(ticket dans l’outil de ticketing, nouvelle fenêtre) | Authentification – Inscription | Le serveur ne vérifie que l'OTP e-mail : maintenir l'OTP téléphone (correctif backend) ou l'abandonner (retrait de l'étape à l'écran) | Amana |
| A2 | Plafond de la prime Voyage Famille au 7ᵉ voyageur P1-D#23(ticket dans l’outil de ticketing, nouvelle fenêtre) | Souscription Voyage | Avec la règle « 2 adultes + 8 enfants », une famille de 10 paie le prix de 7 : trois voyageurs assurés sans contrepartie. Seul point ouvert à impact financier direct | Amana (métier) |
| A3 | Chat du service client P3.12#11(ticket dans l’outil de ticketing, nouvelle fenêtre) | Sinistres | L'API rattache le fil au client, pas au sinistre : la même conversation s'affiche sous chaque dossier. Soit un paramètre de sinistre côté backend, soit un fil unique déplacé vers le menu | Produit / Backend |
| A4 | Périmètre Santé Groupe P3.13#58(ticket dans l’outil de ticketing, nouvelle fenêtre) | Santé Groupe – Contrat santé | Le backend n'expose aucun type de contrat Groupe pour la Santé : confirmer le hors-périmètre de la souscription ou ouvrir un lot backend | Amana |
| A5 | Renouvellements et avenants Santé P1-H#28(ticket dans l’outil de ticketing, nouvelle fenêtre), P1-I#29(ticket dans l’outil de ticketing, nouvelle fenêtre) | Santé Individuelle / Famille – Contrat santé | Les écrans existent, les endpoints refusent tout payload : exclure de la version 1 ou planifier un lot | Amana |
| A6 | Écran de liste des notifications | Menu – Notifications | Le compteur est réel ; l'écran de liste n'a jamais été conçu | Produit |
| A7 | Prérequis client pour la mise en ligne | Transverse | Comptes Google Play et App Store, URL de l'API de production, instance Satim marchande au nom d'Amana (la page de test affiche encore un marchand tiers) | Amana |
| A8 | Prérequis client pour la recette | Transverse | Cartes Dahabia de test (jamais transmises), accès à une boîte mail de test ou OTP fixe en pré-production. Le compte de test jetable est fourni (khaddoucheTest@amana.dz) : des contrats réels y ont été créés et payés | Amana |
| A11 | Validation du livrable transmis | Transverse | Le livrable précédent n'a pas été validé par Amana ; la validation demandée porte sur l'APK de référence (section 1.4), qui le remplace et clôt les sprints 1 et 2 hors points réservés | Amana |
| A9(urgent) | Reconduction de session cassée (constat d'audit, ticket à créer) | Authentification – Connexion, Authentification par empreinte digitale | POST /auth/refresh répond 500 avec un jeton valide : tout utilisateur est déconnecté au bout de 30 minutes, et la connexion par empreinte n'opère que dans cette fenêtre. Correction serveur indispensable avant production | Backend |
| A10(urgent) | Inscription et mot de passe oublié inopérants pour un vrai utilisateur | Authentification – Inscription, Réinitialisation du mot de passe | Rejoués avec la boîte mail de test : l'application envoie l'OTP avant que le compte existe (404) et appelle le mauvais endpoint pour le mot de passe oublié (401). Correctif applicatif livré le jour même (ordre des appels, endpoint, jeton), inclus dans l'APK de référence. Côté backend, le code MFA de connexion n'arrive pas par e-mail et l'OTP est réutilisable jusqu'à expiration | Backend |
Section 1.2 : Par sprint et par workflow
Chaque sprint, puis chaque workflow avec ce qui empêche sa validation, le ticket associé, l’impact, le responsable et le plan de résolution.
Progression de chaque sprint
Sprint 1 · 21 workflows
Authentification, Accueil, Dashboard, Compte, Menu
14/21 intégrés- Bloqués par un ticket ·
- 1 (Documents utiles) + 1 décision produit (Notifications) + 2 défauts applicatifs (Inscription, Réinitialisation)
- Validation client ·
- Livré et testé par le client ; inscription et mot de passe oublié à corriger côté application avant le premier APK
Sprint 2 · 7 workflows
Souscription, Paiement
5/7 intégrés- Bloqués par un ticket ·
- 4 (les quatre moyens de paiement)
- Validation client ·
- Paiement carte encaissé sur les 4 produits ; retour dans l'application et confirmation à corriger côté passerelle
Sprint 3 · 5 workflows
Contrats, Sinistres
4/5 intégrés- Bloqués par un ticket ·
- 1 (Sinistres)
- Validation client ·
- Contrats validables ; la déclaration de sinistre n'est jamais déposée (référentiel non exposé)
Sprint 4 · 6 workflows
Remboursements, Santé Individuelle
5/6 intégrés- Bloqués par un ticket ·
- 1 (Compléter profil santé)
- Validation client ·
- Souscription et remboursement validés en réel, pièces jointes comprises
Sprint 5 · 9 workflows
Santé Famille, Santé Groupe
7/9 intégrés- Bloqués par un ticket ·
- 2 (Compléter profil santé Famille et Groupe)
- Validation client ·
- Même chaîne que l'individuel ; périmètre Santé Groupe à confirmer
| Sprint | Workflows | Intégrés | Hybrides | Locaux |
|---|---|---|---|---|
| Sprint 1 | 21 | 14 | 4 | 3 |
| Sprint 2 | 7 | 5 | 2 | 0 |
| Sprint 3 | 5 | 4 | 1 | 0 |
| Sprint 4 | 6 | 5 | 1 | 0 |
| Sprint 5 | 9 | 7 | 2 | 0 |
État de chaque workflow
Colonnes : État (🟢 intégré, 🟡 hybride, ⚪ local) · Blocage (ce qui empêche la validation) · Ticket · Impact · Responsable · Plan de résolution. Les lots renvoient à l'ordre de résorption de la section 1.4.
| Workflow | État | Blocage · impact · plan de résolution | Ticket | Responsable |
|---|---|---|---|---|
| Authentification · S1 | ||||
| Authentification – Inscription | Hybride | L'application envoie l'OTP e-mail avant de créer le compte : le serveur répond Impact · Aucun nouvel utilisateur ne pouvait s'inscrire ; corrigé côté application (création du compte, puis OTP e-mail), flow Maestro instrumenté Plan · Décision sur l'ordre officiel du parcours ; A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) pour la première connexion | Lot 5 (application, corrigé)A17#64(ticket dans l’outil de ticketing, nouvelle fenêtre)A18#65(ticket dans l’outil de ticketing, nouvelle fenêtre)A23#69(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-D#2(ticket dans l’outil de ticketing, nouvelle fenêtre) | Amana (décision A1) et Backend |
| Authentification – Connexion | Intégré | Reconduction de session cassée ( Impact · Déconnexion forcée après 30 minutes Plan · Lot 1 : correctif serveur, aucun contournement propre possible côté mobile | Ticket à créerA9#1(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.2#30(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Authentification – Réinitialisation du mot de passe | Hybride | L'application appelle Impact · Aucun utilisateur ne pouvait récupérer son mot de passe ; corrigé côté application ( Plan · A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) et A19#66(ticket dans l’outil de ticketing, nouvelle fenêtre) | Lot 5 (application, corrigé)A19#66(ticket dans l’outil de ticketing, nouvelle fenêtre)A20#67(ticket dans l’outil de ticketing, nouvelle fenêtre)A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Authentification par empreinte digitale | Local | Dépend de la reconduction de session A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre) Impact · Ne fonctionne que dans la demi-heure suivant une connexion par mot de passe Plan · Résolu avec A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre) | — | Backend |
Comptes migrés. Les deux branches « ancien compte » du parcours de connexion (liaison d'un second compte, ancien compte Assurance seul) sont construites, traduites et testées, mais inaccessibles : le backend n'a pas encore indiqué le signal qui doit les déclencher ni le contrat réel de POST /auth/attach (9 questions transmises). L'attente porte sur une réponse, pas sur du développement. | ||||
| Accueil · S1 | ||||
| Accueil | Intégré | Aucun ; le badge de notifications est compté côté application faute d'endpoint dédié Impact · Compteur plafonné par la taille de page Plan · Lot 6 | P3.2#43(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Navigation (Barre de navigation inférieure) | Local | Aucun | — | — |
| Dashboard · S1 | ||||
| Dashboard – Liste des contrats | Intégré | Aucun ; ordre de tri et politique d'exclusion non confirmés Impact · Le « dernier contrat » n'est pas identifiable de façon fiable Plan · Lot 6 | P3.15#46(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Dashboard – Liste des sinistres | Intégré | Aucun | — | — |
| Dashboard – Liste des remboursements | Intégré | Aucun | — | — |
| Compte · S1 | ||||
| Compte – Profil utilisateur | Intégré | Aucun ; DTO de Plan · Lot 6 | P2.1#31(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Compte – Profil santé | Intégré | Contrat réel de Impact · Lecture et écriture fonctionnent ; deux relations familiales sont repliées sur « Ascendant » Plan · Lot 2 P1-F#26(ticket dans l’outil de ticketing, nouvelle fenêtre), P1-G#27(ticket dans l’outil de ticketing, nouvelle fenêtre), Lot 4 P0-F#18(ticket dans l’outil de ticketing, nouvelle fenêtre) | P0-F#18(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-F#26(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-G#27(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.13#32(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.19#47(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Compte – Paramètres | Local | Aucun endpoint de préférences exposé : préférences stockées sur l'appareil | — | — |
| Menu · S1 | ||||
| Menu – Contrats | Intégré | Aucun | — | — |
| Menu – Produits | Intégré | Aucun ; garanties renvoyées par formule là où le modèle attend une valeur Impact · Fiche produit en secours seulement Plan · Lot 6 | P3.6#48(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Menu – Actualités | Intégré | Aucun | — | — |
| Menu – Docteur chez moi / Allo Docteur | Intégré | Aucun | — | — |
| Menu – Réseau | Intégré | Aucun | — | — |
| Menu – SOS | Intégré | Contenu servi en français quelle que soit la langue demandée Impact · Expérience arabe incomplète Plan · Lot 6 | P3.16#49(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Menu – Contact | Intégré | Aucun ; pièces jointes plafonnées à 1 Mo par la passerelle Impact · Une photo de téléphone ne passe pas Plan · Lot 2 | P0-I#12(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Menu – Documents utiles | Hybride | 🔴 L'API renvoie un chemin de fichier serveur, pas une URL ; et répond 500 pour tout souscripteur non adhérent santé Impact · Aucun document n'est ouvrable ; écran mort pour la majorité des clients réels, sur un catalogue réglementaire Plan · Lot 2 | P0-H#4(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-L#3(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Menu – Notifications | Hybride | Écran de liste jamais conçu (décision produit A6) Impact · Compteur réel, liste absente Plan · Lot 3 | P3.2#43(ticket dans l’outil de ticketing, nouvelle fenêtre) | Produit |
| Souscription · S2 | ||||
| Souscription Voyage | Intégré | Individuelle, Famille et Groupe vérifiées sur contrats réels et payées. Réserves : l'API répond « succès » sur un échec (contourné par relecture), création en trois appels non atomiques, champs obligatoires ignorés (prix faux en 200), plafond Famille au 7ᵉ voyageur (décision A2), primes négatives possibles sur le type Groupe, compte sans enregistrement souscripteur non signalé Impact · Vendable ; un aller-retour réseau supplémentaire par vente Plan · Lot 1 P1-D#23(ticket dans l’outil de ticketing, nouvelle fenêtre), Lot 4 (P1-A#20(ticket dans l’outil de ticketing, nouvelle fenêtre)/B/C/E) | P1-A#20(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-B#21(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-C#22(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-D#23(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-E#24(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-J#25(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.11#34(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.3#50(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.14#51(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend, Amana (A2) |
| Souscription Accident | Intégré | Individuel vérifié et payé ; la création en groupe répond encore 409 côté backend Impact · Le tunnel Accident groupe n'est pas validable Plan · Lot 2 | (suivi dans le fil Teams, à ticketer) | Backend |
| Souscription Scolaire | Intégré | Aucun ; individuel et groupe vérifiés | — | — |
| Paiement · S2 | ||||
| Paiement CIB | Intégré | 🔴 Paiement réel encaissé sur les 4 produits, mais la passerelle redirige vers le site vitrine au lieu de l'application après le 3-D Secure, et l'endpoint de confirmation nie le paiement qu'il vient d'encaisser (contourné : l'application relit le contrat, d'où jusqu'à 90 s avant l'écran de succès) Impact · Dernier obstacle entre un paiement qui marche et un paiement présentable Plan · Lot 1 | P0-M#5(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-N#6(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend / Satim |
| Paiement Dahabia | Intégré | Page de paiement réelle atteinte ; les cartes Dahabia de test n'ont jamais été transmises Impact · Aucun règlement Dahabia n'a pu être exécuté Plan · Prérequis A8 | (prérequis client)CL-DAHABIA | Amana |
| Paiement Points verts | Hybride | 🔴 L'endpoint de paiement répond 500 sur toute quittance, et c'est un Impact · Cas nominal jamais exécutable Plan · Lot 1 | P0-B#7(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Paiement À la livraison | Hybride | 🔴 L'endpoint de confirmation décrit par l'équipe backend n'existe pas dans la spécification Impact · L'application ne peut pas constater l'encaissement d'un contrat payé à la livraison Plan · Lot 1 | P0-C#8(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Contrats · S3 | ||||
| Contrats – Assurance Voyage | Intégré | Trois données manquent au détail (personnes assurées, libellé du moyen de paiement, valeur par garantie) ; documents de contrat en 404 ; numéro de police absent de la liste ; justificatif de résiliation exigé en base64 (la demande part sans pièces) ; motifs de résiliation non publiés Impact · Validable en lecture ; résiliation incomplète Plan · Lot 2 P3.17#54(ticket dans l’outil de ticketing, nouvelle fenêtre), Lot 6 | P3.5#53(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.4#52(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.5#35(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.17#54(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.18#55(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Contrats – Assurance Accident | Intégré | Idem Impact · Idem Plan · Idem | P3.4#52(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.5#53(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.5#35(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.17#54(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Contrats – Assurance Scolaire | Intégré | Idem Impact · Idem Plan · Idem | P3.4#52(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.5#53(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.5#35(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.17#54(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Carte Flash Amana | Intégré | Aucun ; le statut renvoyé est un texte libre, tout code inconnu est traité comme un refus Plan · Lot 4 | P2.8#36(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Sinistres · S3 | ||||
| Sinistres | Hybride | 🔴 La déclaration n'est jamais déposée : Impact · Le point le plus trompeur du périmètre : l'assuré croit avoir déclaré Plan · Lot 2 P0-K#10(ticket dans l’outil de ticketing, nouvelle fenêtre), Lot 3 P3.12#11(ticket dans l’outil de ticketing, nouvelle fenêtre) | P0-K#10(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.12#11(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend, Produit (A3) |
| Remboursements · S4 | ||||
| Remboursements | Intégré | Déclaration vérifiée de bout en bout, pièces comprises. Pièces plafonnées à 1 Mo par la passerelle (une photo de justificatif pèse 3 à 5 Mo) ; le champ de l'acte a été renommé côté serveur sans préavis (contourné) ; catalogue d'actes sans catégorie ni illustration ; documents d'un remboursement en régression 404 Impact · Le cas nominal (photo de téléphone) ne passe pas tant que la limite n'est pas relevée Plan · Lot 2 P0-I#12(ticket dans l’outil de ticketing, nouvelle fenêtre), Lot 4 P0-G#19(ticket dans l’outil de ticketing, nouvelle fenêtre), Lot 6 | P0-I#12(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-G#19(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.6#37(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.1#56(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.11#57(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Santé Individuelle · S4 | ||||
| Santé Individuelle – Souscription | Intégré | Aucun ; devis, contrat et paiement vérifiés en réel. Aucun code promotionnel valide en base pour tester le coupon Plan · Lot 6 | P3.3#50(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Santé Individuelle – Compléter Profil santé | Hybride | 🔴 Identité, questionnaire et bénéficiaires sont soumis en réel ; le dépôt des pièces (endpoint qui refuse tout sans nommer de champ), les personnes à charge (500 nu) et le bulletin d'adhésion (500 puis absence de réponse) ne répondent pas. Le drapeau Impact · Deux étapes sur cinq opérationnelles ; le profil n'est pas activé tant que le bulletin signé ne revient pas Plan · Lot 2 | P0-J#13(ticket dans l’outil de ticketing, nouvelle fenêtre)§31#14(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.10#15(ticket dans l’outil de ticketing, nouvelle fenêtre)P2.12#38(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Santé Individuelle – Profil santé | Intégré | Aucun | — | — |
| Santé Individuelle – Espace santé | Intégré | Aucun (écran composite sur cinq endpoints) | — | — |
| Santé Individuelle – Contrat santé | Intégré | Lecture réelle ; le devis de renouvellement refuse tout payload (409 opaque) et l'adjonction plante sur son propre DTO d'erreur (500) Impact · Renouvellement et avenants non tarifiables (décision A5) Plan · Lot 3 | P1-H#28(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-I#29(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend, Amana (A5) |
| Santé Famille · S5 | ||||
| Santé Famille – Souscription | Intégré | Aucun ; vérifiée en réel (type de contrat Famille) | — | — |
| Santé Famille – Compléter Profil santé | Hybride | Même chaîne que l'individuel : pièces, personnes à charge et bulletin indisponibles côté serveur Impact · Idem Plan · Lot 2 | P0-J#13(ticket dans l’outil de ticketing, nouvelle fenêtre)§31#14(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.10#15(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Santé Famille – Profil santé | Intégré | Aucun | — | — |
| Santé Famille – Espace santé | Intégré | Aucun | — | — |
| Santé Famille – Contrat santé | Intégré | Renouvellement et adjonction non tarifiables Impact · Idem individuel Plan · Lot 3 | P1-H#28(ticket dans l’outil de ticketing, nouvelle fenêtre)P1-I#29(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend, Amana (A5) |
| Santé Groupe · S5 | ||||
| Santé Groupe – Compléter Profil santé | Hybride | Même chaîne que l'individuel ; la date d'entrée en service, obligatoire pour un adhérent groupe, est désormais collectée Impact · Idem Plan · Lot 2 | P0-J#13(ticket dans l’outil de ticketing, nouvelle fenêtre)§31#14(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.10#15(ticket dans l’outil de ticketing, nouvelle fenêtre) | Backend |
| Santé Groupe – Profil santé | Intégré | Aucun | — | — |
| Santé Groupe – Espace santé | Intégré | Aucun | — | — |
| Santé Groupe – Contrat santé | Intégré | Le backend n'expose aucun type de contrat Groupe pour la Santé (décision A4) Impact · Le référentiel de workflows ne prévoit pas d'entrée « souscription » pour ce segment Plan · Lot 3 | P3.13#58(ticket dans l’outil de ticketing, nouvelle fenêtre) | Amana |
Section 1.3 : Qualité & tests QA
L’état des tests par type, les cas testés, validés et en échec, les anomalies critiques et leur statut, et les points de vigilance.
État des tests QA
| Type de test | Ce qui a été fait | Résultat | Reste à faire |
|---|---|---|---|
| Revue de code et qualité | Branche de câblage final relue et fusionnée ; revue de sécurité (jeton statique et mot de passe OTP partagé retirés du bundle applicatif) ; en-tête rendu hors de la branche d'erreur sur 53 écrans ; trois défauts d'accessibilité corrigés | Typage strict : 0 erreur · Lint : 0 erreur · 351 tests automatisés au vert (66 construits sur des charges utiles capturées en live) | Revue systématique des conteneurs tapables qui masquent leur contenu aux technologies d'assistance ; installer le module natif du bouton « coller » du code OTP au prochain build |
| Tests d'intégration API | Contrôle automatisé du contrat sur les 54 endpoints de lecture ; 9 endpoints d'écriture sur 11 exercés en conditions réelles (résiliation et retrait d'ayant droit exclus) ; harnais de capture des 31 mutations avec les payloads réels de l'application | Contrat intact sur tout endpoint consommé ; 1 dérive sur un endpoint non branché ; 5 contrats mal documentés découverts et absorbés | Rejouer le retrait d'ayant droit et la résiliation sur le compte jetable khaddoucheTest (la suppression de bénéficiaire a été vérifiée en réel : bénéficiaire créé puis supprimé) ; brancher le dépôt des pièces santé et la déclaration de sinistre dès correction backend |
| Tests fonctionnels E2E (Maestro) | 17 parcours écrits et exécutés sur simulateur iPhone contre la pré-production ; 17 vidéos produites, chacune nommant le ticket du mur rencontré. Parcours 02 et 03 rejoués au niveau API avec la boîte mail de test (demo@shiftin-demo.com), sur un compte de recette créé pour l'occasion, avec les payloads exacts de l'application | 17 parcours joués : 11 au bout, 6 arrêtés sur un mur backend. Les parcours 02 et 03 ont d'abord révélé deux défauts applicatifs (inscription : OTP envoyé avant création du compte ; mot de passe oublié : mauvais endpoint et jeton non conservé), corrigés puis réenregistrés de bout en bout, code OTP lu automatiquement dans une boîte jetable ; les 4 tunnels règlent un vrai paiement jusqu'à l'écran de succès | Passe sur appareil réel |
| Tests responsive / UI / accessibilité | Rendu vérifié sur simulateur iOS, RTL arabe compris ; l'automatisation lit l'arbre d'accessibilité | 3 écrans invisibles pour VoiceOver corrigés (feuilles de sélection, sélecteur de wilaya, menu « + ») | Rendu arabe et performance sur appareil réel Android ; contenu éditorial en arabe (dépend du backend, P3.16#49(ticket dans l’outil de ticketing, nouvelle fenêtre)) |
Nombre de cas testés, validés, en échec
| Périmètre | Testés | Validés | En échec ou bloqués | Note |
|---|---|---|---|---|
| Parcours E2E Maestro | 17 | 11 | 6 murs backend | Chaque mur est un ticket nommé ; les deux parcours OTP passent depuis la correction applicative |
| Tunnels de souscription avec paiement réel | 4 | 4 | 0 | Voyage, Scolaire, Accident (individuel), Santé |
| Endpoints de lecture (relevé automatisé) | 54 | 44 valides | 10 en 404 / 500 | Les 404 sur endpoints paramétrés sont des artefacts de sondage, identiques au relevé de référence |
| Endpoints d'écriture exercés en réel | 11 | 9 | 2 non exécutés (retrait d'ayant droit, résiliation) | Compte jetable fourni (khaddoucheTest) : rejeu planifié |
| Chaîne OTP (création de compte, OTP e-mail, validation, réinitialisation, défi MFA) | 18 appels | 15 conformes à l'attendu | 3 défauts bloquants (OTP impossible avant création, MFA non délivré par e-mail, OTP réutilisable) | Rejouée avec la boîte mail de test sur un compte de recette |
| Tests unitaires et d'intégration automatisés | 351 | 351 | 0 | — |
| Workflows validables sans dépendance externe | 48 | 38 | 10 | 9 tickets backend, 1 décision produit |
Résultats de la campagne E2E par workflow
Dix-sept parcours Maestro joués contre la pré-production et filmés ; chaque mur backend est nommé par son ticket.
12 parcours sur 17 vont au bout ; 5 s’arrêtent sur un mur backend, filmé et nommé.
| Parcours | Workflows couverts | Sprint | Verdict | Mur rencontré (ticket) | Vidéo |
|---|---|---|---|---|---|
| 01 · Connexion | Authentification – Connexion, Authentification par empreinte digitale | S1 | Va au bout Au bout | — | |
| 02 · Onboarding + inscription | Authentification – Inscription | S1 | Va au bout Au bout (compte créé, code OTP lu et saisi, écran de succès) | Défaut applicatif corrigé (l'OTP partait avant la création du compte). Côté serveur : OTP par téléphone impossible , OTP téléphone non vérifié , politique de mot de passe non appliquée à la créationA23#69(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-D#2(ticket dans l’outil de ticketing, nouvelle fenêtre)A18#65(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 03 · Mot de passe oublié | Authentification – Réinitialisation du mot de passe | S1 | Va au bout Au bout (code lu et saisi, mot de passe réinitialisé, écran de succès) | Défauts applicatifs corrigés (endpoint, jeton, bouton « Continuer » sous le clavier). Côté serveur : OTP réutilisable , MFA non délivré par e-mail après réinitialisationA19#66(ticket dans l’outil de ticketing, nouvelle fenêtre)A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 04 · Accueil + navigation | Accueil, Navigation, Menu – Notifications | S1 | Va au bout Au bout | — | |
| 05 · Dashboard | Dashboard – Contrats / Sinistres / Remboursements | S1 | Va au bout Au bout | — | |
| 06 · Compte + profil + paramètres | Compte – Profil utilisateur / Profil santé / Paramètres | S1 | Va au bout Au bout | — | |
| 07 · Menu — contenu | Menu – Produits / Actualités / Allo Docteur / Réseau | S1 | Va au bout Au bout | — | |
| 08 · Menu — SOS, contact, documents | Menu – SOS / Contact / Documents utiles | S1 | Mur backend filmé Mur backend | Aucun document téléchargeable, 500 hors adhérent santéP0-H#4(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-L#3(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 09 · Souscription Voyage + paiement | Souscription Voyage, Paiement CIB / Dahabia / Points verts / À la livraison | S2 | Va au bout Au bout (paiement encaissé) | La passerelle ramène sur le site vitrineP0-M#5(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 10 · Souscription Scolaire + paiement | Souscription Scolaire, Paiement CIB | S2 | Va au bout Au bout (paiement encaissé) | — | |
| 11 · Souscription Accident + paiement | Souscription Accident, Paiement CIB | S2 | Va au bout Au bout (individuel) | Création en groupe en 409 côté backend | |
| 12 · Souscription Santé + paiement | Santé Individuelle / Famille – Souscription | S4 / S5 | Va au bout Au bout (paiement encaissé) | Écran de succès après relecture du contratP0-N#6(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 13 · Contrats, carte Flash, résiliation | Menu – Contrats, Contrats – Voyage / Accident / Scolaire, Carte Flash Amana, Contrat santé (3 segments) | S3 / S4 / S5 | Mur backend filmé Mur backend | Résiliation sans pièces jointesP3.17#54(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 14 · Déclaration de remboursement | Remboursements | S4 | Va au bout Au bout (pièces comprises) | Limite de 1 Mo par fichierP0-I#12(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 15 · Déclaration de sinistre | Sinistres | S3 | Mur backend filmé Mur backend | Rien n'est déposé , filmé comme preuveP0-K#10(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 16 · Espace santé + profil santé + assistant | Espace santé, Profil santé, Compléter profil santé (3 segments) | S4 / S5 | Mur backend filmé Mur backend | Personnes à charge , pièces , bulletin§31#14(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-J#13(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.10#15(ticket dans l’outil de ticketing, nouvelle fenêtre) | |
| 17 · Chat service client | Sinistres | S3 | Mur backend filmé Mur backend | Fil unique par clientP3.12#11(ticket dans l’outil de ticketing, nouvelle fenêtre) |
Anomalies critiques et leur statut
Anomalies critiques côté backend, visibles en recette — ouvertes.
| Sévérité | Anomalie | Workflow(s) | Ticket | Statut |
|---|---|---|---|---|
| Bloquant | Session détruite au bout de 30 minutes (/auth/refresh → 500) | Authentification – Connexion, Empreinte digitale | À créerA9#1(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert, aucun contournement propre |
| Bloquant | Le code MFA de connexion n'est pas délivré par e-mail : /auth/mfa/send {channel: EMAIL} répond succès, aucun e-mail n'arrive ; un compte réinitialisé ne peut plus se connecter | Authentification – Connexion | À créerA22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert |
| Bloquant | L'OTP e-mail est réutilisable jusqu'à expiration (validé trois fois avec le même code) ; un code vide expose une exception SQL | Authentification – Réinitialisation du mot de passe | À créerA19#66(ticket dans l’outil de ticketing, nouvelle fenêtre)A21#68(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert |
| Bloquant | La passerelle ne ramène pas dans l'application après le 3-D Secure | Paiement CIB | P0-M#5(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert |
| Bloquant | L'endpoint de confirmation nie un paiement encaissé | Paiement CIB | P0-N#6(ticket dans l’outil de ticketing, nouvelle fenêtre) | Contourné (relecture du contrat, jusqu'à 90 s) |
| Bloquant | La déclaration de sinistre n'est jamais déposée | Sinistres | P0-K#10(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert |
| Bloquant | Documents utiles : 500 hors adhérent santé, aucune URL téléchargeable | Menu – Documents utiles | P0-L#3(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-H#4(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert |
| Bloquant | Pièces jointes plafonnées à 1 Mo | Remboursements, Contact, Compléter profil santé | P0-I#12(ticket dans l’outil de ticketing, nouvelle fenêtre) | Contourné (compression, refus expliqué) ; cas nominal toujours en échec |
| Bloquant | Dépôt des pièces du profil santé impossible (aucun champ nommé) ; personnes à charge en 500 ; bulletin d'adhésion en 500 | Compléter profil santé (3 segments) | P0-J#13(ticket dans l’outil de ticketing, nouvelle fenêtre)§31#14(ticket dans l’outil de ticketing, nouvelle fenêtre)P3.10#15(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert |
| Bloquant | Paiement Points verts en 500 ; confirmation du paiement à la livraison inexistante | Paiement Points verts, Paiement À la livraison | P0-B#7(ticket dans l’outil de ticketing, nouvelle fenêtre)P0-C#8(ticket dans l’outil de ticketing, nouvelle fenêtre) | Ouvert |
| Bloquant | Messages d'erreur servis en ISO-8859-1 : les textes français arrivent illisibles | Tous les écrans affichant un message serveur | À créer | Ouvert |
Points de vigilance liés à la qualité
- La campagne n'a jamais tourné sur Android, ni sur un appareil physique. Caméra, biométrie, page de paiement en WebView et rendu arabe exigent la passe sur appareil réel prévue au plan de recette.
- Les codes OTP sont désormais lus automatiquement en recette : un pont local relève une boîte IMAP ou une boîte jetable créée à la volée (la pré-production délivre bien vers ces domaines), et les flows Maestro 02 et 03 le consultent. La boîte
amana@shiftin-demo.comtransmise refuse l'authentification IMAP ; les comptes de recette créés aujourd'hui ne peuvent pas ouvrir de session tant que le code MFA n'est pas délivré par e-mail A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre). - Deux opérations destructrices n'ont jamais été exécutées en réel (retrait d'ayant droit, résiliation) : seul leur comportement d'erreur est vérifié. Le compte jetable existe (
khaddoucheTest@amana.dz, déjà utilisé pour des paiements réels et la navigation) : il reste à y rejouer ces deux opérations avant la mise en production. La suppression de bénéficiaire, elle, a été vérifiée en réel. - Le compte de test de souscription n'a pas d'enregistrement souscripteur côté
/auth/meP1-J#25(ticket dans l’outil de ticketing, nouvelle fenêtre) : les tunnels ont dû être rejoués sur le compte santé. En production, un client dans ce cas remplirait tout le tunnel pour un échec final. - Le paiement de test s'exécute sur une page marchande au nom d'un tiers ; une page nommant une autre société ne peut pas être livrée.
- 50 écrans partagent encore le schéma « conteneur tapable qui masque son contenu » trouvé trois fois par hasard : une revue systématique est planifiée.
- L'URL de l'API de production configurée dans l'application est encore factice, et la télémétrie n'est pas branchée : les dégradations seraient muettes en production.
- Les données de recette restent en place sur les deux comptes de test (décision client), préfixées
RECpour rester distinguables.
Section 1.4 : Timeline & prochaines étapes
La seule section du board à porter des dates : écarts par rapport au planning initial, livrables qui font foi, organisation par chantiers, calendrier et échéances.
Écarts par rapport au planning initial
| Jalon « Mise en ligne » | Planning V1 | Planning V2 (en vigueur contractuellement) | Planning par chantiers (cible : 22/10/2026, butoir : 29/10/2026) |
|---|---|---|---|
| Publication Play Store / App Store | 31/08/2026 → 06/09/2026 | 22/09/2026 → 28/09/2026 | 14/10/2026 → 22/10/2026 |
| Lancement | 06/09/2026 | 28/09/2026 | 22/10/2026 (butoir 29/10/2026) |
| Phase Q&A | 10/08 → 13/08/2026 | 01/09 → 21/09/2026 | Recette continue à partir du 24/09 ; QA final 11/10 → 13/10/2026 |
| Écart cumulé | — | + 22 jours calendaires | + 24 jours par rapport au V2, + 46 jours par rapport au V1 |
Livrables : ce qui a été transmis, ce qui fait foi
| Livrable | Statut | Ce qu'il contient |
|---|---|---|
| APK transmis le 24/08/2026 | Reçu par Amana, non validé à ce jour ; remplacé | Sprints 1 et 2 sur API réelle, hors authentification |
| APK preview QA du 17/09/2026 | Construit, remplacé le 19/09 | Tous les écrans sur l'API réelle, authentification comprise, quatre tunnels payés en réel |
| APK preview QA du 19/09/2026 | Livrable de référence : c'est celui-ci que nous demandons à Amana de valider, en remplacement du 24/08 | Le contenu du 17/09, plus l'inscription et le mot de passe oublié corrigés (défauts trouvés le 19/09 en rejouant les parcours avec une boîte mail) et la checklist de mot de passe sur la politique serveur ; accompagné du dashboard, des 17 vidéos de recette (inscription et mot de passe oublié réenregistrées de bout en bout) et du registre des tickets |
| APK 1 du 24/09/2026 · APK 2 du 01/10/2026 · APK 3 du 08/10/2026 (release candidate) | À livrer, chaque jeudi | Correctifs backend des chantiers 1 à 3 vérifiés en réel |
Pourquoi abandonner le découpage par sprint
Le Planning V2 enchaîne, pour chacun des cinq sprints, un cycle complet « intégration → APK interne → QA → APK client → tests client → corrections ». Ce découpage était pertinent pour l'intégration statique ; il ne l'est plus. Le travail restant n'est pas réparti par sprint, il est réparti par blocage : un correctif de passerelle de paiement débloque quatre tunnels de quatre sprints différents, un correctif de téléversement débloque le remboursement (S4), le contact (S1) et le profil santé (S5). Recycler cinq fois la même chaîne ferait attendre chaque correctif jusqu'au cycle de « son » sprint. Le planning ci-dessous organise donc la fin du projet par chantiers de blocage, en livraison continue, avec une seule porte de sortie : la liste des bloquants de mise en production (section 3.0) vide et vérifiée.
| Principe | Concrètement |
|---|---|
| Trois chantiers en parallèle, un binôme backend + mobile par chantier | Chantier 1 « Vente et paiement » · Chantier 2 « Compte et session » · Chantier 3 « Dossiers, documents et santé » (contenu ci-dessous) |
| Chaque correctif backend est vérifié en réel dans les 24 h par l'équipe mobile, avec les payloads de l'application, et un test automatisé est écrit sur la réponse capturée | Plus aucun endpoint codé d'après la documentation ; le ticket est fermé sur preuve, pas sur annonce |
| Un build de recette par jour, un APK client chaque jeudi | Le client teste en continu sur le dernier APK au lieu d'attendre une fenêtre de deux jours ; retours consolidés chaque dimanche matin |
| Point quotidien de 15 minutes backend + mobile + PM sur la liste 3.0 | Un seul tableau, celui de l'outil de ticketing, filtré sur les bloquants |
| La release candidate est coupée le premier jeudi où la liste 3.0 est vide | Cible : 08/10/2026. Butoir : 15/10/2026 |
| Les décisions produit (A1 à A6) sont rendues en une seule séance | Le 22/09/2026, en ouverture du chantier |
Les trois chantiers
1 · Vente et paiement (chemin critique)
Les quatre tunnels payés de bout en bout, présentables, sur les quatre moyens de paiement
Tickets · P0-M#5(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-N#6(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-B#7(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-C#8(ticket dans l’outil de ticketing, nouvelle fenêtre), A14#9(ticket dans l’outil de ticketing, nouvelle fenêtre) (Accident groupe), P1-D#23(ticket dans l’outil de ticketing, nouvelle fenêtre) (décision A2), cartes Dahabia (CP-08), instance Satim au nom d'Amana (CP-12)
Chantier 1Côté backend
returnUrlvers le lien profond,confirmPaymentcohérent avec l'encaissement, Points verts enPOSTavec erreurs typées, confirmation livraison,409Accident groupeCôté mobile
Retrait de la garde de relecture dès P0-N#6(ticket dans l’outil de ticketing, nouvelle fenêtre), rejeu automatisé des quatre tunnels à chaque correctif, règlement Dahabia dès réception des cartes
2 · Compte et session
Créer un compte, se connecter, rester connecté, récupérer son mot de passe
Tickets · A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre) (
/auth/refresh→500), A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) (code MFA non délivré par e-mail), P0-D#2(ticket dans l’outil de ticketing, nouvelle fenêtre) (décision A1), A17#64(ticket dans l’outil de ticketing, nouvelle fenêtre) à A21#68(ticket dans l’outil de ticketing, nouvelle fenêtre), A23#69(ticket dans l’outil de ticketing, nouvelle fenêtre) (chaîne OTP), A10#17(ticket dans l’outil de ticketing, nouvelle fenêtre) (UTF-8), Q1-Q9#71(ticket dans l’outil de ticketing, nouvelle fenêtre) (comptes migrés)Chantier 2Côté backend
Réparer
/auth/refresh, délivrer le code MFA, trancher l'ordre du parcours d'inscription, rendre l'OTP à usage unique, répondre aux 9 questionsauth/attachCôté mobile
Corriger l'inscription (créer le compte avant l'OTP) et le mot de passe oublié (
/auth/otppuis jeton de validation versPATCH /auth/password) — défauts applicatifs trouvés le 19/09 grâce à la boîte mail ; instrumenter ces écrans pour Maestro et réenregistrer les parcours 02 et 033 · Dossiers, documents et santé
Déclarer un sinistre, joindre une photo, ouvrir un document utile, compléter un profil santé
Tickets · P0-K#10(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-I#12(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-L#3(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-H#4(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-J#13(ticket dans l’outil de ticketing, nouvelle fenêtre), §31#14(ticket dans l’outil de ticketing, nouvelle fenêtre), P3.10#15(ticket dans l’outil de ticketing, nouvelle fenêtre), P3.12#11(ticket dans l’outil de ticketing, nouvelle fenêtre) (décision A3), P3.17#54(ticket dans l’outil de ticketing, nouvelle fenêtre)
Chantier 3Côté backend
Référentiel
produitde/claims, plafond d'upload à 10 Mo avec413,/documentsservi à tous avec une URL, contrat deaddPieceJointe,POST /ayantDroits, bulletin d'adhésion, paramètre de sinistre sur le chat, résiliation multipartCôté mobile
Déposer réellement une déclaration de sinistre et les pièces santé dès livraison, résiliation avec pièces, rejeu du parcours 15 et 16
Transverse, hors chemin critique
Fiabiliser le contrat pour la suite (lot 4) et le confort (lot 6)
Tickets · P0-F#18(ticket dans l’outil de ticketing, nouvelle fenêtre), P0-G#19(ticket dans l’outil de ticketing, nouvelle fenêtre), P1-A#20(ticket dans l’outil de ticketing, nouvelle fenêtre)/B/C/E, P2.x, P3.x restants
Chantier 4Côté backend
Documentation,
required, enveloppes, énumérationsCôté mobile
Retrait des contournements au fil des correctifs
Calendrier
Jours ouvrés algériens (dimanche → jeudi) ; aucun jour férié sur la période.
| Semaine | Backend | Mobile | Client | Jalon du jeudi |
|---|---|---|---|---|
| 20/09 → 24/09/2026 | Ouverture des trois chantiers ; correctifs du chantier 1 et de A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre) / A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) engagés en priorité | Premier build de recette quotidien ; retrait de la garde de relecture dès P0-N#6(ticket dans l’outil de ticketing, nouvelle fenêtre) ; rejeu automatisé des tunnels à chaque correctif reçu | Séance de décisions A1 à A6 le 22/09 ; validation de l'APK du 19/09 ; cartes Dahabia ; comptes stores demandés | APK 1 · 24/09 : APK du 19/09 + premiers correctifs backend vérifiés |
| 27/09 → 01/10/2026 | Livraison des correctifs des chantiers 1 et 2 ; démarrage du chantier 3 | Vérification live sous 24 h de chaque correctif ; passe sur appareil réel (caméra, biométrie, paiement, arabe, Android) du 28 au 30/09 ; rejeu de la résiliation et du retrait d'ayant droit sur khaddoucheTest le 01/10 | Tests continus sur l'APK 1, retours le dimanche 27/09 | APK 2 · 01/10 : paiement présentable, session stable |
| 04/10 → 08/10/2026 | Livraison des correctifs du chantier 3 ; reste transverse | Déclaration de sinistre, pièces santé, documents utiles rejoués en réel ; campagne Maestro complète (17 + 2 parcours) sur le build du 07/10 | Tests continus sur l'APK 2, retours le 04/10 ; compte App Store fourni au plus tard le 04/10 | APK 3 · 08/10 = release candidate si la liste 3.0 est vide |
| 11/10 → 15/10/2026 | Astreinte corrective sur la RC | QA final 11 → 13/10 ; version iOS (build, TestFlight, fiche) 11 → 14/10 ; soumission aux stores le 14/10 | Recette finale sur la RC 11 → 13/10 ; comptes stores, URL de production, instance Satim Amana fournis | 15/10 : soumissions déposées (ou APK 4 = RC de repli si la liste 3.0 n'était pas vide le 08/10) |
| 18/10 → 22/10/2026 | — | Suivi de la revue Apple, correctifs de revue | Validation de mise en ligne | Lancement le 22/10/2026 |
| Butoir · repli25/10 → 29/10/2026 | Réservé au repli : RC du 15/10, QA final 18 → 20/10, soumission 21/10 | Lancement au plus tard le 29/10/2026 |
Hypothèses sans lesquelles la date ne tient pas
- Les correctifs du chantier 1 et A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre) / A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) sont livrés au plus tard le 01/10/2026, ceux du chantier 3 le 08/10/2026 ; chaque correctif est accompagné d'un exemple de requête fonctionnelle.
- Les décisions A1 à A6 sont rendues le 22/09/2026.
- Le compte App Store est disponible le 04/10/2026, le compte Play Store, l'URL de l'API de production et une instance Satim au nom d'Amana le 13/10/2026.
- La revue Apple aboutit entre le 14 et le 22/10 ; à défaut, Android est lancé le 22/10 et iOS suit dès approbation.
Prochaines échéances clés
- 22/09/2026Séance de décisions A1 à A6 ; ouverture des chantiers ; point quotidien en placeCondition · Disponibilité des décideurs
- 24/09/2026APK 1 : premiers correctifs backend du chantier 1 vérifiés en réelCondition · Correctifs livrés et validation de l'APK du 19/09 par Amana
- 27/09/2026Premiers retours client sur l'APK 1Condition · —
- 01/10/2026APK 2 : correctifs du chantier 1 (paiement) et de la session A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre), A22#16(ticket dans l’outil de ticketing, nouvelle fenêtre) vérifiés en réel ; résiliation et retrait d'ayant droit rejoués sur
khaddoucheTestCondition · Correctifs backend livrés - 04/10/2026Compte App Store fourniCondition · Amana
- 08/10/2026APK 3 = release candidate ; liste 3.0 vide et vérifiéeCondition · Correctifs du chantier 3 livrés
- 13/10/2026Fin du QA final ; comptes stores, URL de production, instance Satim Amana fournisCondition · Amana
- 14/10/2026Soumission Play Store et App StoreCondition · —
- 22/10/2026LancementCondition · Revue Apple aboutie
- 29/10/2026Butoir de lancement (repli d'une semaine)Condition · —