Équipe backend · Opérationnel, directement exploitable
17 points bloquent la mise en production. Ils sont listés à part, en tête ; tout le reste est classé par priorité, et chaque ligne renvoie à son ticket.
Bloquants pour la mise en production
17
section 3.0 : à traiter avant toute autre
Tickets dans l’outil de ticketing
71 / 71
un par référence, rattaché à son workflow
Ouverts, correctif serveur attendu
50
aucune absorption côté application
Contournés côté application
16
l’application absorbe le défaut ; le correctif reste attendu
La colonne « N° » porte le numéro attribué par l'outil de ticketing ; la référence (P0-M#5(ticket dans l’outil de ticketing, nouvelle fenêtre), P1-A#20(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), §31#14(ticket dans l’outil de ticketing, nouvelle fenêtre), A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre)…) est la clé stable reprise dans le titre de chaque ticket. Priorités : P0 = critique / bloquant pour une mise en production · P1 = haute (défaut de fiabilité de contrat) · P2 = normale (alignement du contrat et de la documentation) · P3 = à traiter ultérieurement (endpoints manquants ou insuffisants). Statuts : ouvert · contourné (l'application absorbe le défaut, le correctif reste attendu) · arbitrage (décision attendue) · résolu. Les échéances cibles renvoient aux lots du plan d'action (section 2.3) ; leur calendrier est en section 1.4. Les 16 tickets bloquants pour la mise en production sont sortis de ces listes et regroupés en section 3.0.
Liste à part, à traiter avant toute autre. Tant qu'un seul de ces points est ouvert, l'application ne peut pas être publiée : soit une fonction livrée n'opère pas, soit un client réel subirait un défaut visible ou dangereux. Ils sont sortis des listes par priorité de la section 3.1. Tous relèvent des lots 1 et 2 du plan d'action, attendus à la fin de la semaine de traitement des issues (calendrier en section 1.4). Le détail de chaque ticket est en section 3.2.
17 points · 13 ouverts, 2 contournés côté application, 2 en arbitrage. Tant qu’un seul reste ouvert, l’application ne peut pas être publiée.
| N° | Réf. | Workflow | Titre | Ce qui casse en production | Statut | Responsable |
|---|---|---|---|---|---|---|
| #1 (nouvelle fenêtre) | A9 | Authentification – Connexion, Empreinte digitale | POST /auth/refresh répond 500 avec un jeton valide | Tout utilisateur est déconnecté au bout de 30 minutes ; la connexion par empreinte n'opère que dans cette fenêtre ; aucun contournement propre côté mobile | Ouvert | Backend |
| #2 (nouvelle fenêtre) | P0-D | Authentification – Inscription | Vérifier l'OTP téléphone à l'inscription | Un compte peut être créé avec un numéro dont l'utilisateur n'est pas titulaire | Arbitrage attendu (A1) | Amana puis Backend |
| #3 (nouvelle fenêtre) | P0-L | Menu – Documents utiles | Servir GET /documents à tout souscripteur | Écran mort pour la majorité des clients réels, sur un catalogue réglementaire public | Ouvert | Backend |
| #4 (nouvelle fenêtre) | P0-H | Menu – Documents utiles | Exposer une URL téléchargeable pour les documents utiles | Aucun document n'est ouvrable | Ouvert | Backend |
| #5 (nouvelle fenêtre) | P0-M | Paiement CIB | Revenir dans l'application après le 3-D Secure | Le client paie puis reste sur le site vitrine, dans le navigateur | Ouvert | Backend / Satim |
| #6 (nouvelle fenêtre) | P0-N | Paiement CIB | confirmPayment nie le paiement qu'il vient d'encaisser | Sans le contournement, écran d'échec après un paiement réussi ; avec, jusqu'à 90 s avant l'écran de succès | Contourné côté app | Backend |
| #7 (nouvelle fenêtre) | P0-B | Paiement Points verts | Paiement Points verts répond 500 | Moyen de paiement inopérant ; un GET exécute un débit, rejouable par rafraîchissement | Ouvert | Backend |
| #8 (nouvelle fenêtre) | P0-C | Paiement À la livraison | Exposer la confirmation du paiement à la livraison | L'encaissement d'un contrat payé à la livraison reste invisible | Ouvert | Backend |
| #9 (nouvelle fenêtre) | A14 | Souscription Accident | Création Accident en groupe répond 409 sans message | Le produit Accident n'est pas vendable en groupe | Ouvert | Backend |
| #10 (nouvelle fenêtre) | P0-K | Sinistres | Exposer le référentiel « produit » de POST /claims | La déclaration de sinistre n'est jamais déposée | Ouvert | Backend |
| #11 (nouvelle fenêtre) | P3.12 | Sinistres | Rattacher le chat du service client à un sinistre | La même conversation s'affiche sous chaque dossier ; un message envoyé depuis l'un apparaît sous tous les autres | Arbitrage attendu (A3) | Produit / Backend |
| #12 (nouvelle fenêtre) | P0-I | Remboursements, Menu – Contact, Compléter profil santé | Relever la limite de téléversement | Une photo de justificatif prise avec un téléphone (3 à 5 Mo) est refusée : cas nominal en échec | Contourné côté app (compression, refus expliqué) | Backend |
| #13 (nouvelle fenêtre) | P0-J | Compléter profil santé (Individuelle, Famille, Groupe) | Publier le contrat de POST /members/addPieceJointe | Les pièces du profil santé n'ont nulle part où aller | Ouvert | Backend |
| #14 (nouvelle fenêtre) | §31 | Compléter profil santé (Individuelle, Famille, Groupe) | POST /ayantDroits répond un 500 nu | Les personnes à charge ne sont jamais soumises | Ouvert | Backend |
| #15 (nouvelle fenêtre) | P3.10 | Compléter profil santé (Individuelle, Famille, Groupe) | GET /members/bulletinAdhesion répond 500 | Le bulletin réclamé par la validation d'adhérent est introuvable ; le profil n'est jamais activé | Ouvert | Backend |
| #16 (nouvelle fenêtre) | A22 | Authentification – Connexion | Le code MFA de connexion n'est pas délivré par e-mail | Un compte qui a réinitialisé son mot de passe (ou un compte neuf après le changement forcé) ne peut plus ouvrir de session | Ouvert | Backend |
| #17 (nouvelle fenêtre) | A10 | Transverse | Servir tout le JSON en UTF-8 | Les messages d'erreur français affichés à l'utilisateur arrivent illisibles | Ouvert | Backend |
| Réf. | Workflow | Défaut | Correctif | Échéance |
|---|---|---|---|---|
| APP-1 | Authentification – Inscription | L'OTP e-mail était envoyé avant POST /users ; le serveur répond 404 pour toute adresse nouvelle | Corrigé : le compte est créé à l'étape téléphone, puis l'adresse est vérifiée par l'OTP ; l'étape SMS (non envoyable, A23#69(ticket dans l’outil de ticketing, nouvelle fenêtre)) est retirée ; écrans instrumentés, flow Maestro 02 réenregistré de bout en bout | Livré dans l'APK de référence |
| APP-2 | Authentification – Réinitialisation du mot de passe | Étape 1 sur POST /auth/mfa/send (jeton obligatoire) au lieu de POST /auth/otp ; jeton de /auth/otp/validate non conservé pour PATCH /auth/password | Corrigé : /auth/otp à l'étape 1, jeton conservé (préfixe Bearer retiré) et porté vers PATCH /auth/password, tests unitaires sur la chaîne ; flow Maestro 03 réenregistré de bout en bout | Livré dans l'APK de référence |
| Réf. | Besoin | Ce qui est bloqué sans lui | Responsable |
|---|---|---|---|
| CP-02 | Compte App Store (organisation, D-U-N-S, certificats) | Build iOS, TestFlight, publication | Amana |
| CP-01 | Compte Google Play Store | Publication Android | Amana |
| CP-11 | URL de l'API de production | Build de production (l'URL configurée est encore factice) | Amana |
| CP-12 | Instance Satim marchande au nom d'Amana | Le paiement carte de test s'exécute sur une page au nom d'un marchand tiers, non livrable | Amana / Satim |
| CP-08 | Cartes Dahabia de test | Le paiement Dahabia n'a jamais été réglé de bout en bout | Amana |
| CP-03 | Décision A1 : authentification par téléphone | Ticket P0-D#2(ticket dans l’outil de ticketing, nouvelle fenêtre) | Amana |
| CP-04 | Décision A2 : plafond de la prime Voyage Famille au 7ᵉ voyageur | Trois voyageurs sur dix assurés sans contrepartie tant que non tranché | Amana |
Critiques, haute priorité, priorité normale, à traiter ultérieurement, et les constats d’audit ticketés depuis cette édition. Les bloquants de mise en production sont marqués et remontent en tête.
| #1 (nouvelle fenêtre) | A9 | P0 · critique | Authentification – Connexion, Empreinte digitale | POST /auth/refresh répond 500 avec un jeton validebloquant prod | Ouvert | Backend | Lot 1 |
| #2 (nouvelle fenêtre) | P0-D | P0 · critique | Authentification – Inscription | Vérifier l'OTP téléphone à l'inscriptionbloquant prod | Arbitrage attendu | Amana puis Backend | Lot 1 |
| #3 (nouvelle fenêtre) | P0-L | P0 · critique | Menu – Documents utiles | Servir GET /documents à tout souscripteurbloquant prod | Ouvert | Backend | Lot 2 |
| #4 (nouvelle fenêtre) | P0-H | P0 · critique | Menu – Documents utiles | Exposer une URL téléchargeable pour les documents utilesbloquant prod | Ouvert | Backend | Lot 2 |
| #5 (nouvelle fenêtre) | P0-M | P0 · critique | Paiement CIB | Revenir dans l'application après le 3-D Securebloquant prod | Ouvert | Backend / Satim | Lot 1 |
| #6 (nouvelle fenêtre) | P0-N | P0 · critique | Paiement CIB | confirmPayment nie le paiement qu'il vient d'encaisserbloquant prod | Contourné côté app | Backend | Lot 1 |
| #7 (nouvelle fenêtre) | P0-B | P0 · critique | Paiement Points verts | Paiement Points verts répond 500bloquant prod | Ouvert | Backend | Lot 1 |
| #8 (nouvelle fenêtre) | P0-C | P0 · critique | Paiement À la livraison | Exposer la confirmation du paiement à la livraisonbloquant prod | Ouvert | Backend | Lot 1 |
| #10 (nouvelle fenêtre) | P0-K | P0 · critique | Sinistres | Exposer le référentiel « produit » de POST /claimsbloquant prod | Ouvert | Backend | Lot 2 |
| #12 (nouvelle fenêtre) | P0-I | P0 · critique | Remboursements, Menu – Contact, Compléter profil santé | Relever la limite de téléversementbloquant prod | Contourné côté app | Backend | Lot 2 |
| #13 (nouvelle fenêtre) | P0-J | P0 · critique | Compléter profil santé (Individuelle, Famille, Groupe) | Publier le contrat de POST /members/addPieceJointebloquant prod | Ouvert | Backend | Lot 2 |
| #14 (nouvelle fenêtre) | §31 | P0 · critique | Compléter profil santé (Individuelle, Famille, Groupe) | POST /ayantDroits répond un 500 nubloquant prod | Ouvert | Backend | Lot 2 |
| #16 (nouvelle fenêtre) | A22 | P0 · critique | Authentification – Connexion | Le code MFA de connexion n'est pas délivré par e-mailbloquant prod | Ouvert | Backend | Lot 1 |
| #17 (nouvelle fenêtre) | A10 | P0 · critique | Transverse | Servir tout le JSON en UTF-8bloquant prod | Ouvert | Backend | Lot 1 |
| #9 (nouvelle fenêtre) | A14 | P1 · haute | Souscription Accident | Création Accident en groupe répond 409 sans messagebloquant prod | Ouvert | Backend | Lot 2 |
| #11 (nouvelle fenêtre) | P3.12 | P3 · ultérieure | Sinistres | Rattacher le chat du service client à un sinistrebloquant prod | Arbitrage attendu | Produit / Backend | Lot 3 |
| #15 (nouvelle fenêtre) | P3.10 | P3 · ultérieure | Compléter profil santé (Individuelle, Famille, Groupe) | GET /members/bulletinAdhesion répond 500bloquant prod | Ouvert | Backend | Lot 2 |
| #18 (nouvelle fenêtre) | P0-F | P0 · critique | Compte – Profil santé, Compléter profil santé | Documenter le contrat réel de PUT /members | Contourné côté app | Backend | Lot 4 |
| #19 (nouvelle fenêtre) | P0-G | P0 · critique | Remboursements | Annoncer les renommages de champ | Contourné côté app | Backend | Lot 4 |
| #66 (nouvelle fenêtre) | A19 | P0 · critique | Authentification – Réinitialisation | OTP réutilisable jusqu'à expiration | Ouvert | Backend | Lot 1 |
| #20 (nouvelle fenêtre) | P1-A | P1 · haute | Souscription Voyage | Ne plus répondre « succès » sur un échec (V8b) | Contourné côté app | Backend | Lot 4 |
| #21 (nouvelle fenêtre) | P1-B | P1 · haute | Souscription Voyage | Rendre la souscription Voyage atomique (V8c) | Ouvert | Backend | Lot 4 |
| #22 (nouvelle fenêtre) | P1-C | P1 · haute | Souscription Voyage | Valider réellement les champs obligatoires (V5) | Contourné côté app | Backend | Lot 4 |
| #23 (nouvelle fenêtre) | P1-D | P1 · haute | Souscription Voyage | Trancher le plafonnement de la prime Famille au 7ᵉ voyageur (V13) | Arbitrage attendu | Amana | Lot 1 |
| #24 (nouvelle fenêtre) | P1-E | P1 · haute | Souscription Voyage | Corriger les primes négatives (V12) | Ouvert | Backend | Lot 4 |
Relevés par l’audit « API réelle vs spécification » et la recette OTP ; hors bloquants de mise en production, déjà listés ci-dessus.
| N° | Réf. | Workflow | Constat | Priorité |
|---|---|---|---|---|
| #59 (nouvelle fenêtre) | A11 | Souscription, Paiement | Idempotence et compensation aucune idempotence sur | P1 · haute |
| #60 (nouvelle fenêtre) | A12 | Authentification | Jeton client portant 19 rôles le JWT d'un simple assuré porte 19 rôles dont des périmètres de back-office ; au moins un est inerte sur cette passerelle. Questions : les 18 autres sont-ils inertes partout ? Le compte de test est-il représentatif ? | P1 · haute |
| #61 (nouvelle fenêtre) | A13 | Souscription Santé, Voyage | Montants en flottants non arrondis
| P2 · normale |
| #62 (nouvelle fenêtre) | A15 | Contrats | 500 divulguant un chemin de service interne | P2 · normale |
| #63 (nouvelle fenêtre) | A16 | Transverse | Remplir les required de la spécification et corriger les cinq écarts actifs par ordre de nocivité : | P1 · haute |
| #64 (nouvelle fenêtre) | A17 | Authentification – Inscription | Aucun OTP possible avant POST /users
| P1 · haute |
| #65 (nouvelle fenêtre) | A18 | Authentification – Inscription | Politique de mot de passe non appliquée à POST /users
| P1 · haute |
| #66 (nouvelle fenêtre) | A19 | Authentification – Réinitialisation | OTP réutilisable jusqu'à expiration
| P0 · critique sécurité |
| #67 (nouvelle fenêtre) | A20 | Authentification – Réinitialisation | 409 « Code generated déja » pendant 15 min
| P1 · haute |
| #68 (nouvelle fenêtre) | A21 | Authentification – Réinitialisation | code vide → 409 exposant une SQLGrammarException
| P1 · haute sécurité |
| #69 (nouvelle fenêtre) | A23 | Authentification – Inscription | POST /auth/otp par numéro de téléphone → 404
| P1 · haute |
| #70 (nouvelle fenêtre) | A24 | Authentification | Jeton renvoyé avec le préfixe Bearer dans la valeur
| P3 · ultérieure |
| #71 (nouvelle fenêtre) | Q1-Q9 | Authentification – Connexion | Comptes migrés et POST /auth/attach modèle du compte unifié, identifiant stable de la personne, rôle exact de l'endpoint, session porteuse de l'appel, contenu du | P1 · haute |
Organisé par workflow, dans l’ordre du référentiel. Pour chaque ticket : description, impact, priorité, responsable, statut, dépendances et échéance cible (lot). Le détail complet est dans l’outil.
POST /auth/otp/validate
500 INTERNAL_SERVER_ERROR. Un corps avec un autre nom de champ répond 400 « refreshToken ne doit pas être vide », ce qui confirme que la requête de l'application est correcte. La spécification est juste ; l'implémentation est cassée.POST /auth/login
419 (changement de mot de passe imposé) et 420 (MFA requis) arrivent avec un jeton porteur sans champ status ; une connexion est rejetée si un JWT périmé est attaché.PATCH /auth/password
GET /auth/password-policy répond désormais, en anonyme, quatre règles en français (8 caractères minimum ; majuscule, minuscule, chiffre et caractère spécial parmi @ # ! ? $ £ ; pas d'informations personnelles ; différent des 5 derniers mots de passe). L'application les affiche et les évalue à chaque frappe. Reste : déclarer l'endpoint dans la spécification, et faire nommer par le 419 la règle violéePOST /auth/mfa/send
420 INSERT_CODE_MULTIFACTORIELLE, OTP, mfa/verify) a été rejouée sur le compte de recette demo@shiftin-demo.com, seule adresse dont la boîte est relevée. Aucun code n'arrive par e-mail après le 420 (attente 2 min) ; POST /auth/mfa/send répond 200 « RESENDING WITH SUCCESS !!! » pour EMAIL, email, MAIL, avec username et à corps vide, sans qu'aucun e-mail ne soit délivré (INBOX, Junk, spam), sur une adresse qui reçoit bien l'OTP de /auth/otp. POST /auth/mfa/verify avec un code erroné répond proprement 400. Si le code part par SMS, ce n'est ni documenté ni observable.POST /auth/otp, POST /auth/otp/validate, POST /users
POST /auth/otp répond 404 « User Not found » pour toute adresse non inscrite et pour tout numéro de téléphone A17#64(ticket dans l’outil de ticketing, nouvelle fenêtre), A23#69(ticket dans l’outil de ticketing, nouvelle fenêtre) ; POST /users crée le compte sans OTP préalable (201) ; un mot de passe accepté par POST /users est refusé en 419 CHANGE_PASSWORD à la première connexion, la politique n'étant pas appliquée à la création A18#65(ticket dans l’outil de ticketing, nouvelle fenêtre) ; POST /auth/otp répond 409 « Code generated déja » pendant les 15 minutes de validité A20#67(ticket dans l’outil de ticketing, nouvelle fenêtre) ; POST /auth/otp/validate accepte le même code plusieurs fois et émet un nouveau jeton à chaque fois A19#66(ticket dans l’outil de ticketing, nouvelle fenêtre) ; un code vide expose une SQLGrammarException A21#68(ticket dans l’outil de ticketing, nouvelle fenêtre) ; le jeton est renvoyé avec le préfixe Bearer A24#70(ticket dans l’outil de ticketing, nouvelle fenêtre)docs/rapports-internes/ (référencée en section 2.3)LoginDto renvoyé, cas d'échec et idempotence, déclencheur côté application (checkuser ? altern_users ?), parcours « ancien compte Assurance seul ». Point connexe : le CIN collecté à l'inscription n'a aucun champ dans POST /users.curl complet d'un rattachement réussi, un compte de test possédant deux anciens comptes non rattachés, la réponse à Q8.400. À rapprocher de l'absence de prix minimum sur GET /produits, qui impose un appel /tarifs par produit à l'accueil.GET /contrats, /beneficiaries, /notifications, /refunds, /claims
/refunds, /claims et /beneficiaries répondent 500 sans page ; la spécification documente encore l'enveloppe retirée.page)souscripteur, adresse, tel, email, wilaya) ; nom/prenom vides à la racine ; deux champs déclarés n'existent pas. L'endpoint le plus utilisé de l'application (10 hooks) est documenté à 22 %souscripteur{})questionnaire et non bonneSanteQuestion ; réponses en chaînes « Oui »/« Non » ; validation (téléphone 10 chiffres, code postal 5 chiffres, ville et date d'entrée en service obligatoires) documentée nulle part ; aucun champ pour la wilaya.POST /beneficiaries
LienParenteEnum n'accepte que Conjoint, Enfant, Ascendant ; le produit propose aussi « frère/sœur » et « autre ». SexeEnum : Masculin / FémininAAAAMMJJ est acceptée ; JJ/MM/AAAA (le format que l'endpoint renvoie en lecture) répond 400, les formes ISO 422.DELETE /ayantDroits/{id}/demandeSuppression
500 sur identifiant inconnu ; l'ayant droit continue d'être renvoyé sans indicateur après la demande.(partagé avec Carte Flash Amana)
statut de la carte Flash vaut la chaîne "false".500 dès que l'appelant n'est pas adhérent santé (route interne bulletinV2DocumentUtil/{adherentId} : « cet adherent n'existe pas »), sur un catalogue de textes réglementaires publics404 amont en 404fichier est un chemin de fichier serveur (opt/amana-digitale-preprod/…) ; GET /assets?path= répond 404/a-propos-amana/sos, /documents, /actes/groups
accept-language ignoréguarantees: [] et force le repli sur cet endpoint.(partagé avec Remboursements) — POST /nousContacter, POST /refunds, DELETE /ayantDroits/{id}/demandeSuppression
/nousContacter répond 500 « Required part 'nom' is not present » sur champ manquant.POST /souscriptions/voyage
201 success: true avec un contratId qui répond ensuite 404. Le backend indique que le contrôle est fait en amont sur la création de l'assuré principal ; un contrôle côté appelant ne remplace pas une validation côté APIGET /contrats/{id} après chaque souscription (un aller-retour par vente), à retirer dès correction.400/404 avec le motif quand une personne ou un contrat référencé n'existe pasPOST /personnes/assure → POST /souscriptions/voyage → POST /personnes/membre-assure
500 Cannot invoke "…toEntity()" because "dto" is null.400/404 au lieu de 500POST /simulation-voyage
age omis → 200 avec un prix plausible mais faux ; destinationId omis → bascule silencieuse sur une autre destination ; dateEffet/dateFin omis → 500 « date must not be null »POST /simulation-voyage (Groupe)
GET /auth/me, POST /souscriptions
personneId ni bloc souscripteur dans /auth/me alors que /auth/login renvoie personne_id ; POST /souscriptions exige personneId.GET /professions
profession en chaîne libre ; 354 professions arrivent non triéesPOST /promoCode/validate (partagé avec Santé – Souscription)
409 ; la simulation hors santé ignore un coupon inconnu en silence, la Santé le refuse.POST /simulation-voyage
recommandee: true est apparu depuis sur list_formule sans annonce.POST /souscriptions (types 533 / 529)
typeContratId communiquée par le backend, la création en groupe répond 409 Bad Request sans message./souscriptions, /souscriptions/voyage, /modePaiement/* ; aucune compensation (DELETE) sur un contrat non payé.Idempotency-KeyPOST /modePaiement/CIB (returnUrl)
site-test.amana.dz, le site vitrine, au lieu du lien profond de l'application. Vérifié sur des paiements réellement encaissés, sur les quatre produits.GET /modePaiement/confirmPayment/{orderId}
valid: false, tous champs nuls, sur un contrat passé à ENCAISSE avec police émise ; deux appels à plusieurs minutes d'intervalle, même réponseGET /points-verts/paiement/{quittanceId}
500 systématique depuis le premier signalement, reproduit pendant près de deux mois ; 500 nu sur solde insuffisant ; c'est un GET qui exécute un débit404 sur quittance inconnue, 409 sur solde insuffisant, méthode POSTconfirmPayment/livraison/{quittanceId}
(prérequis client, hors outil de ticketing)
Voyage, Accident, Scolaire
GET /contrats/{id}
GET /coverages/{produitId} à chaque ouverture.POST /avenant/resiliation
AvenantDTO.justificatif est une chaîne base64 là où tous les autres téléversements sont multipart ; 500 sur contrat inconnu, divulguant un chemin interneGET /avenant/motifs.POST /carteFlash/checkTicketValidation (voir Compte)
statut vaut la chaîne "false"produit doit correspondre à un référentiel « produit sinistre » qu'aucun endpoint mobile n'expose ; dix valeurs candidates (codes produit, identifiants, libellés) échouent sur Attempt to read property "produit_sinistre_id" on null. Piège associé : le validateur nomme date_naiss, date_sinistre, path_files alors que l'endpoint lit dateNaiss, dateSinistre, piecesGET /chat/history, POST /chat/send
updatedAt déclaré mais absent.sinistreId (l'écran fonctionne alors tel quel), ou un fil unique déplacé vers le menutous les téléversements (POST /refunds, /nousContacter, profil santé)
500 « Maximum upload size exceeded » sans nom de champ ni limite. Mesuré : 1 024 Kio accepté, 1 200 Kio refusé, deux fichiers de 600 Kio dans le même appel acceptés (plafond par fichier)max-file-size porté à 10 Mo, et un 413 ou un 422 nommant la pièce et la limitePOST /refunds
type à codeActe côté serveur sans préavis ; l'ancien nom répond 404 « Acte non trouvé » ; la spécification documente le champ retiré et omet celui qui fonctionne.Evenement ; catégorie et illustration déduites côté mobile.Compléter profil santé (3 segments)
422 « The given data was invalid. » sans nommer de champ ; plus de 25 noms de parties testés, en fichier comme en texte ; une seule propriété identifiée (rib, String) par fuite d'erreur de conversion.curl fonctionnel suffirait) ou un validateur qui nomme les champs manquants, comme le fait /refundsCompléter profil santé (3 segments)
500 quels que soient les champs, aucun champ nomméCompléter profil santé (3 segments)
declare: false produit le même message et le même effet que declare: truePOST /avenants/{contratId}/renouvellements/sante/devis — Contrat santé (Individuelle, Famille)
409 « problem devis Renouvellement Sante » à tout payload : six contrats (individuel et famille, encaissés et non payés), les deux valeurs de modifyDevis, types 530 et 531, formule en libellé et en identifiant. Aucun champ nommé, aucune raisonPOST /avenants/{contratId}/adjonctions/sante/devis
error est typé int alors que le service amont renvoie la chaîne "409 :" ; la passerelle plante sur sa propre gestion d'erreur et répond 500, masquant le refus métier réel.Santé Groupe – Contrat santé
POST /souscriptions/devis-souscription-sante
primeNetteSansReduction: 16164.146341463415, primeNetteSansReductionMensuel: 1347.0121951219512 ; reduction: false alors que les variantes avec et sans réduction diffèrent/beneficiaries renvoie JJ/MM/AAAA et refuse ce même format en écriture./destination/getGlobal, /auth/refresh, /members
personne_id chaîne vs personneId entier ; {key, value} au lieu de {id, label} ; PoliceId en PascalCase ; code_reference / codeReference selon le résultatrequired: [] alors que l'API valide strictement.required rendrait le générateur de code utilisable et supprimerait 1 968 lignes maintenues à la main./nousContacter, /refunds, /members, /chat/send, /auth/refresh
application/json;charset=ISO-8859-1 (« Acc?s refus? » une fois décodé en UTF-8)/avenant/resiliation
POST /refunds (documente type, retiré ; omet codeActe) → PUT /members (questionnaire plat au lieu d'imbriqué) → GET /auth/me (5 champs au lieu de 18 + 4 objets) → /refunds et /claims (enveloppe retirée) → /simulation-voyage (type: string au lieu de JSON). Documenter GET /produits/{id}/detail. Déclarer les 4xx réellement renvoyés. Ouvrir /api-docs au compte mobile ou publier la spécification dans le dépôt.| Réf. | Besoin | Bloque | Responsable |
|---|---|---|---|
| CP-01 | Compte Google Play Store | Publication Android | Amana |
| CP-02 | Compte App Store (organisation, D-U-N-S, certificats) | Build iOS, TestFlight, publication | Amana |
| CP-03 | Décision : authentification par téléphone (A1) | Sprint 1 — inscription | Amana |
| CP-04 | Décision : plafond de la prime Voyage Famille (A2) | Sprint 3 — Voyage | Amana |
| CP-05 | Décision : chat par sinistre ou fil unique (A3) | Sprint 3 — Sinistres | Produit |
| CP-06 | Décision : périmètre Santé Groupe (A4) | Sprint 5 | Amana |
| CP-07 | Décision : renouvellements et avenants Santé (A5) | Sprint 5 | Amana |
| CP-08 | Cartes Dahabia de test | Sprint 2 — paiement Dahabia | Amana |
| CP-09 | Compte de test jetable en pré-production | ✅ Fourni : khaddoucheTest@amana.dz, déjà utilisé pour des paiements réels ; il reste à y rejouer la résiliation et le retrait d'ayant droit | Amana / Backend |
| CP-10 | Accès à une boîte mail de test ou OTP fixe en pré-production | Recette des parcours inscription et mot de passe oublié | Amana / Backend |
| CP-11 | URL de l'API de production | Build de production | Amana |
| CP-12 | Instance Satim marchande au nom d'Amana | Paiement carte en production | Amana / Satim |
| CP-13 | Validation de l'APK de référence (section 1.4), qui remplace le livrable précédent non validé | Clôture des sprints 1 et 2 | Amana |
Le reporting ne présente que ce qui sert au suivi et à la priorisation ; le détail complet de chaque ticket est dans l’outil de ticketing.
Outil de ticketing AMANA-MOBILE
71 tickets, un par référence des sections 3.0 et 3.1, rattachés au projet de leur workflow. L’outil fait foi pour le statut.
https://amana-support.shiftin-demo.com/ — un ticket par ligne des sections 3.0 et 3.1 (55 demandes du registre plus les constats A9#1(ticket dans l’outil de ticketing, nouvelle fenêtre) à A24#70(ticket dans l’outil de ticketing, nouvelle fenêtre) et les questions Q1-Q9#71(ticket dans l’outil de ticketing, nouvelle fenêtre)), rattaché au projet correspondant à la clé du workflow (par exemple paiement-cib, sinistres, sante-individuelle-completer-profil-sante), titre préfixé par la référence stable. Chaque ticket porte l'endpoint, le comportement observé, le comportement attendu, l'impact et les références aux documents internes. Les accès nominatifs de l'équipe backend sont transmis séparément.curl de reproduction) docs/BACKEND_CHANGES_wire-remaining-app-flows.md ; le registre des anomalies et l'ordre de résorption API_Remaining_Tasks_Issues.md ; l'audit « API réelle vs spécification » audit-api-reel-vs-specification.md ; les questions sur les comptes migrés docs/backend-requests/QUESTIONS_AUTH_ATTACH.md.yarn api:probe (54 endpoints de lecture, sans écriture), yarn api:contract (comparaison au contrat figé, distinction entre rupture sur endpoint consommé et dérive sur endpoint non branché), scripts/capture-live-mutations.mts --dry-run --tier 4 (les 31 payloads réels de l'application, rien d'envoyé).https://reporting-amana.164-132-116-139.nip.io/ (hôte provisoire jusqu'au rattachement du sous-domaine reporting-amana.octera.tech), sections Livraison APK, QA, Statut, Timeline, Planning ; filtres par sprint et par workflow dans l'URL ; export CSV et Excel.