Deployment, training & maintenance
Requirements OPS-01 to OPS-06: environments, deployment, training, maintenance and support, acceptance and the pilot, within the three-month V1 frame.
This area covers how V1 reaches production and is run (cahier §12, §13, §14). Binding frame (AUTHORING §1): design, development and deployment of V1 take three months from 18 Oct 2026; V1 — including the reseller web — goes to production at the start of January 2027, followed by a two-week pilot; generalisation and V2 come after the three months. Dates come from the plan: see the timeline. Owner: Anis for DevOps, with Imad for the stores and Akram for training material. Technical details: deployment and operations.
| ID | Requirement | Release | Priority | Source | Apps |
|---|---|---|---|---|---|
OPS-01 | Three environments: development, pre-production (client acceptance), production | V1 | MUST | §13.1 | OPS |
OPS-02 | Deployment: server, database, storage, backups, domains, certificates, external services, store publication | V1 | MUST | §13.2 | OPS |
OPS-03 | Training: administrators and managers, delegates on a full tour scenario, reseller quick guide, admin documentation and support procedures | V1 | MUST | §13.3 | OPS |
OPS-04 | Maintenance: warranty period, corrective/preventive/evolutive maintenance, support SLAs and priorities, monitoring and security updates | V1 | MUST | §13.4 | OPS |
OPS-05 | Acceptance: priority scenarios pass, blocking defects fixed, acceptance report (PV) signed | V1 | MUST | §12 | OPS |
OPS-06 | Pilot with a limited group of delegates and resellers, then progressive generalisation | V1 | MUST | §14 | OPS |
3-month frame: design → development → deployment — deadline 17 Jan 2027.
| Date | Milestone | Target | Reached when these tasks end |
|---|---|---|---|
| 18 Oct 2026 | Cadrage validated — validation sheet signed | — | PRJ-03 |
| 18 Oct 2026 | API contract v1 published (OpenAPI + mock server) | — | SRV-03 |
| 19 Oct 2026 | Server V1 feature-complete | — | SRV-26, SRV-40 |
| 21 Oct 2026 | Design system v1 ready (tokens + components) | — | DES-04 |
| 22 Oct 2026 | Screen inventory frozen | — | DES-05 |
| 29 Oct 2026 | Reseller app designs ready for client review | — | DES-10 |
| 05 Nov 2026 | Delegate app designs ready for client review | — | DES-14 |
| 08 Nov 2026 | Mobile foundations ready | — | MOB-11 |
| 12 Nov 2026 | Back-office designs ready for client review | — | DES-19 |
| 16 Nov 2026 | Design handoff complete | — | DES-21 |
| 03 Dec 2026 | Back-office and reseller web V1 feature-complete | — | DSH-12, WEB-05, WEB-06 |
| 15 Dec 2026 | Mobile apps V1 feature-complete | — | MDA-12 |
| 22 Dec 2026 | Staging integration complete | — | MOB-14, SRV-28 |
| 28 Dec 2026 | Acceptance report (PV de recette) signed | — | QA-02 |
| 29 Dec 2026 | Production go-live | on time — 17 Jan 2027 | LCH-01 |
| 30 Dec 2026 | Pilot starts | on time — 17 Jan 2027 | LCH-02 |
| 14 Jan 2027 | Pilot go / no-go | — | LCH-03, LCH-03B |
| 21 Jan 2027 | Generalisation complete | — | LCH-05 |
| 22 Feb 2027 | V2 delivered | — | SRV-38, DSH-21, MDA-20, WEB-20, DQA-12 |
OPS-01 — Environments
Statement — The system shall run in separate development, pre-production (client acceptance) and production environments.
Rules
- Environments: local (docker compose), staging (auto-deployed from
dev, team integration), pre-production / recette (release candidates, HOCO's acceptance), production (tags onmaster). The cahier's three environments map to local + staging (development), pre-production and production. - Each environment has its own database, storage buckets, secrets, Firebase project and app flavor, maps keys and domains (
api-staging.hoco.dz, …; D-12). - Production personal data is never copied to other environments without anonymisation; providers run in simulator or sandbox mode outside production.
Acceptance criteria
- A build tagged on
masterdeploys only to production; a staging app cannot authenticate against production.
Data — none.
Interfaces — none.
OPS-02 — Deployment
Statement — The team shall deploy and configure the server, database, storage, backups, domains, certificates, external services and store publication.
Rules
- Go-live checklist: server, back-office and reseller web on Dokploy with TLS; database migrations applied after a backup; storage buckets and lifecycle rules; nightly backups verified and one restore done; domains and DNS; provider accounts in HOCO's name (INT-07); monitoring and alerts live (NFR-08); initial imports of products, resellers, users and stock (ADM-06); invitation landing and app-link files live.
- Stores: both Android apps on the Play closed track for pilot users at go-live, public track at generalisation; data-safety form, location declaration, privacy policy and store assets ready (MOB-14, DQA-01). iOS only on D-10.
- Releases outside 08:00–18:00 Sunday–Thursday, downtime under 5 minutes, documented rollback (previous image + backup).
Acceptance criteria
- The go-live checklist is signed with every item checked; pilot users install both apps from the closed track and use the reseller web on production.
Data — all.
Interfaces — none.
OPS-03 — Training
Statement — The team shall train administrators and managers, train delegates on a complete tour scenario, provide a reseller quick guide, and hand over administration documentation and support procedures.
Rules
- Before the pilot: back-office sessions per role (commercial, stock, finance, delivery, direction); pilot delegates trained on a full tour (start, navigation, check-in, visit, report, sign-up, invitation, assisted order, offline, closing); reseller quick guide (PDF and in-app link) for pilot resellers covering the app and the web.
- At generalisation: remaining delegates trained wave by wave (LCH-05).
- Materials in French (DQA-06): reseller guide, delegate field guide, back-office quick-reference cards; this docs site is the administration reference; support procedures say who handles what and how to escalate.
- Attendance recorded; every trained delegate completes one tour on pre-production or in the pilot.
Acceptance criteria
- Every pilot delegate has an attendance record and closed a full training tour; the support procedure is handed to HOCO.
Data — none.
Interfaces — none.
OPS-04 — Maintenance and support
Statement — Maintenance shall define a warranty period, corrective, preventive and evolutive maintenance, support delays and priorities, and monitoring and security updates.
Rules
-
Warranty: corrective maintenance included for a period to specify in the contract (decided: 2 months after go-live).
-
Priorities and targets (proposal, working hours Sunday–Thursday):
Priority Example Response Fix or workaround P1 blocking API down, orders or check-ins impossible 2 h 1 working day P2 major a feature broken without workaround 1 working day 5 working days P3 minor cosmetic, workaround exists 3 working days next release P4 evolution new need — backlog, quoted -
Preventive: monthly dependency and OS updates, critical security fixes within 7 days, certificate and backup checks, quarterly restore test.
-
Evolutive work follows the change process (D-38 for what moves after go-live).
Acceptance criteria
- The maintenance terms (warranty, priorities, delays) are in the signed contract; the monthly update log exists after go-live.
Data — none.
Interfaces — none.
OPS-05 — Acceptance (recette)
Statement — V1 shall be accepted when the priority scenarios pass, blocking defects are fixed and the acceptance report (PV) is signed.
Rules
- Priority scenarios of §12: reseller account, catalog, order, stock, tracking, promotion, loyalty, tour, GPS, prospect, invitation, first order, report, permissions, offline. Loyalty is V2: its scenario is deferred and noted in the PV; the others are executed on the reseller app, the reseller web, the delegate app and the back-office (acceptance scenarios).
- Sequence: team integration tests on staging (QA-01) and scripted functional campaign (QA-03), then HOCO's acceptance on pre-production (QA-02).
- Exit: every V1 priority scenario passed, 0 open blocking (P1) defects, major (P2) defects with an agreed workaround and date, PV signed — milestone Acceptance report signed, before Production go-live.
Acceptance criteria
- The signed PV lists each scenario with its result on each app and the open defects with their priority.
Data — none.
Interfaces — none.
OPS-06 — Pilot then progressive generalisation
| Release | Priority | Source | Apps | Owner tasks |
|---|---|---|---|---|
| V1 | MUST | cahier §14 | OPS | LCH-03, LCH-04, LCH-05, LCH-03B, DQA-08, MOB-18 |
Statement — After go-live, V1 shall run for two weeks with a limited group of delegates and resellers, then open progressively.
Rules
- Pilot group (proposal, D-32): 3 to 5 delegates in one or two zones and their 30 to 60 resellers, using the apps and the reseller web; two calendar weeks right after the January go-live, before Ramadan.
- Daily triage of defects and KPIs, hotfixes on the closed track and production (LCH-03, LCH-03B); UX observation in the field (DQA-08).
- Go / no-go criteria (proposal): no open P1; crash-free sessions ≥ 99 %; ≥ 99 % of queued sync items applied without manual action; ≥ 80 % of check-ins within tolerance (input for D-06); orders processed end to end from every channel.
- Generalisation after the three months: waves by zone with training, public store track (LCH-05); pilot improvements first (LCH-04, MOB-18).
Acceptance criteria
- A go / no-go report with the measured criteria is signed by HOCO at the end of the pilot (milestone Pilot go / no-go).
Data — analytics aggregates (ANA-04).
Interfaces — none.
Security, privacy & compliance
Requirements SEC-01 to SEC-08 with measurable rules and verification: password hashing, sessions and attempt limits, HTTPS, protected files, backups, deactivation without loss, geolocation consent and Law 18-07 compliance.
Cross-cutting requirements
Non-functional, security and privacy requirements in measurable form — performance budgets, availability and backups, scalability, compatibility, responsive back-office, i18n and RTL, accessibility, exports, logging and alerting, security controls, privacy and quality gates — each with its acceptance and its verification.