QUBITDT

Manuel de livraison des plateformes de bornes bancaires libre-service

Version : 1.0
Statut : Document de travail interne
Propriétaire : Qubit Digital Technology
Périmètre : Plateforme de bornes bancaires libre-service, micro-services associés, intégrations au système d'information bancaire et supervision du parc
Projet de référence : BIIC — Banque cliente
Contact : infi@qubitdt.com

---

1. OBJECTIF DU MANUEL

Ce manuel définit le processus standard utilisé par Qubit Digital Technology pour concevoir, développer, intégrer, déployer et maintenir ses plateformes de bornes bancaires libre-service, logicielles et matérielles.

L'objectif est de permettre à qubitdt de :

• livrer ses projets de manière reproductible;
• réduire les risques de projet;
• améliorer la qualité des déploiements;
• clarifier les responsabilités;
• protéger les données bancaires et personnelles;
• garantir qu'aucune opération financière n'est perdue ni comptabilisée deux fois;
• assurer une validation adéquate des fonctions monétiques et biométriques;
• faciliter le passage d'un projet vers les opérations et le support;
• mesurer la qualité et la performance des solutions.

Le processus doit être adapté au niveau de risque, à la taille du parc, à la criticité des services offerts et au contexte réglementaire du client.

---

2. PORTFOLIO QUBITDT

2.1 Plateforme de bornes bancaires — établissements bancaires

Solution destinée principalement aux banques et aux établissements financiers.

Elle peut notamment couvrir :

• dépôt d'espèces et de chèques;
• consultation de comptes et historique;
• paiement de factures et de services tiers;
• ouverture de compte avec enrôlement KYC;
• authentification multicanal (carte/PIN, QR code, NFC/RFID, biométrie);
• émission et personnalisation de cartes EMV sur la borne;
• téléassistance, prise de rendez-vous, réclamations;
• supervision technique, transactionnelle et de sécurité du parc;
• intégrations avec les systèmes existants (CBS, switch monétique, CRM, GED, AML/KYC);
• échanges de données interbancaires.

Le déploiement d'un parc de bornes doit être considéré comme un projet critique : une interruption, une erreur de comptage ou une mauvaise configuration peut avoir des conséquences financières, comptables et réglementaires immédiates pour l'établissement.

---

3. SERVICES LIBRE-SERVICE — PARCOURS CLIENT

Les parcours embarqués sur la borne sont destinés directement aux clients de la banque, sans intervention d'un agent.

Le processus doit mettre l'accent sur :

• simplicité d'utilisation;
• parcours court (maximum 5 étapes);
• accessibilité (WCAG 2.2 niveau AA, EAA);
• langue locale;
• assistance vocale pour les parcours complexes;
• consentement explicite du client;
• protection des données personnelles et biométriques;
• lisibilité des reçus et des justificatifs;
• comportement clair en cas d'erreur ou d'indisponibilité;
• sécurisation automatique en cas d'inactivité;
• téléassistance et escalade vers un agent;
• mesure de l'usage et du taux d'abandon.

Les parcours à impact financier (dépôt, paiement, émission de carte) doivent être soumis à une validation spécifique avant leur mise à disposition.

---

4. PLATEFORME D'INTÉGRATION BANCAIRE

L'intégration au système d'information de la banque et à l'écosystème interbancaire constitue un domaine à part entière.

Le processus doit notamment couvrir :

• définition du cas d'utilisation;
• systèmes à intégrer (CBS, switch monétique, CRM, GED, moteurs AML/KYC, plateforme de communication);
• protocoles et formats (ISO 8583, ISO 20022, REST/SOAP);
• gouvernance des données;
• authentification et gestion des clés;
• idempotence et réconciliation;
• traçabilité et journalisation;
• sécurité et contrôle des accès;
• reporting;
• exigences contractuelles;
• exigences réglementaires (BCEAO, PCI DSS, RGPD et réglementation locale);
• déploiement et support.

Les obligations comptables, monétiques, réglementaires et commerciales du client doivent être clairement séparées et documentées.

---

5. CYCLE DE VIE STANDARD D'UN PROJET

Chaque projet qubitdt suit autant que possible le cycle suivant :

SOP-001 — Qualification
↓
SOP-002 — Discovery
↓
SOP-003 — Analyse des besoins
↓
SOP-004 — Proposition et cadrage
↓
SOP-005 — Conception
↓
SOP-006 — Architecture
↓
SOP-007 — Développement / Configuration
↓
SOP-008 — Intégration des données et systèmes
↓
SOP-009 — Tests
↓
SOP-010 — Validation client
↓
SOP-011 — Préparation Go-Live
↓
SOP-012 — Déploiement
↓
SOP-013 — Hypercare
↓
SOP-014 — Passage au support
↓
SOP-015 — Exploitation et amélioration continue

---

6. SOP-001 — QUALIFICATION DU PROJET

Objectif

Déterminer si le projet correspond aux capacités, aux objectifs et au niveau de risque acceptable pour qubitdt.

Étapes

• Enregistrer le prospect.
• Identifier le type d'établissement.
• Identifier les utilisateurs et les parcours attendus.
• Comprendre le problème principal.
• Identifier les services à embarquer sur la borne.
• Identifier les périphériques nécessaires.
• Identifier les données nécessaires.
• Identifier les systèmes à intégrer.
• Identifier les contraintes de sécurité et de certification.
• Identifier les contraintes réglementaires applicables.
• Évaluer la complexité et la taille du parc.
• Estimer les ressources nécessaires (logiciel, matériel, déploiement terrain).
• Déterminer si une Discovery est nécessaire.

Questions essentielles

• Quel problème doit être résolu?
• Qui utilisera la borne?
• Combien de bornes et quels volumes de transactions sont concernés?
• Quels services financiers sont concernés?
• Des espèces ou des chèques sont-ils acceptés?
• Quelles données seront utilisées?
• S'agit-il de données de carte ou de données biométriques?
• Où les données sont-elles actuellement stockées?
• Quels systèmes doivent être intégrés (CBS, switch, CRM, GED, AML/KYC)?
• Quel switch monétique et quel CBS sont en place?
• Quelle décision ou action la solution doit-elle supporter?
• Quel est le niveau de criticité?
• Quelles sont les attentes du client concernant la disponibilité et le mode dégradé?
• Quelles sont les exigences de sécurité et de certification (PCI DSS, PCI PTS, EMV)?

Critère de sortie

Le projet est : Accepté pour Discovery / Mis en attente / Refusé.

---

7. SOP-002 — DISCOVERY

Objectif

Comprendre précisément le besoin avant de concevoir la solution. La Discovery doit être documentée.

Participants

Selon le projet :

• équipe qubitdt;
• responsable projet;
• équipe technique;
• équipe matériel et déploiement terrain;
• experts métier de la banque;
• représentants du client;
• responsables monétique;
• responsables TI;
• sécurité;
• responsables données;
• conformité et représentants réglementaires lorsque nécessaire.

Activités

7.1 Cartographie du processus actuel

Documenter : Processus actuel en agence → Problèmes → Besoin → Parcours libre-service proposé

7.2 Identification des utilisateurs

Créer une liste des personas :

• client de la banque;
• prospect en cours d'ouverture de compte;
• agent d'agence;
• conseiller back-office KYC;
• superviseur NOC;
• technicien de maintenance terrain;
• responsable monétique;
• responsable conformité;
• administrateur de la plateforme;
• équipe TI de la banque.

7.3 Identification des données

Documenter :

• source;
• type (transactionnelle, carte, document d'identité, biométrique);
• format;
• propriétaire;
• sensibilité;
• fréquence de mise à jour;
• destination;
• durée de conservation applicable;
• contrôles d'accès.

7.4 Identification des intégrations

Pour chaque intégration :

• système;
• propriétaire;
• méthode d'intégration;
• protocole (ISO 8583, ISO 20022, REST, SOAP);
• API;
• fréquence;
• données échangées;
• authentification;
• idempotence;
• gestion des erreurs;
• réconciliation;
• monitoring.

7.5 Identification du parc et des sites

Pour chaque site d'implantation :

• emplacement et conditions d'exploitation;
• services activés sur la borne;
• périphériques installés;
• connectivité réseau;
• alimentation électrique et onduleur;
• vidéosurveillance et sécurité physique;
• horaires d'accès et de collecte;
• responsable local.

---

8. SOP-003 — REQUIREMENTS

Chaque projet doit posséder un document d'exigences approuvé.

8.1 Exigences fonctionnelles

Exemple : REQ-F-001 Le client authentifié doit pouvoir déposer des espèces et recevoir un reçu daté, sans qu'aucun crédit ne soit annoncé avant confirmation du comptage.

8.2 Exigences non fonctionnelles

Exemples :

• performance;
• disponibilité;
• mode dégradé;
• sécurité;
• évolutivité;
• auditabilité;
• compatibilité matérielle;
• accessibilité.

8.3 User Story

Format recommandé : En tant que [utilisateur], je veux [fonction] afin de [objectif].

8.4 Critères d'acceptation

Chaque fonctionnalité importante doit posséder des critères mesurables.

Exemple :

• utilisateur autorisé;
• action réalisée;
• résultat attendu;
• preuve produite (reçu, journal, écriture);
• comportement en cas d'erreur;
• comportement en mode dégradé.

---

9. SOP-004 — GESTION DU PÉRIMÈTRE

Tout changement important après validation des exigences doit être documenté.

Change Request

Chaque demande doit préciser :

• numéro;
• demandeur;
• date;
• description;
• raison;
• impact fonctionnel;
• impact technique;
• impact matériel et périphériques;
• impact sécurité et certification;
• impact données;
• impact monétique et comptable;
• impact calendrier;
• impact coût;
• approbation.

Aucun changement important ne doit être considéré comme automatiquement inclus dans le projet initial.

---

10. SOP-005 — CONCEPTION DE LA SOLUTION

La conception doit transformer les exigences en solution réalisable.

Elle doit couvrir :

• architecture;
• interface kiosque;
• parcours utilisateur;
• données;
• APIs;
• intégrations;
• authentification;
• autorisations;
• matériel et périphériques;
• monitoring;
• mode dégradé;
• sauvegarde;
• reprise après incident.

Un diagramme d'architecture doit être produit lorsque la complexité du projet le justifie.

10.1 Principes directeurs — contraintes fondamentales

Toute décision de conception doit pouvoir être justifiée au regard des cinq principes suivants :

Principe	Contrainte
Security, Privacy & Compliance by Design	Chaque couche intègre sécurité et conformité dès la conception
Aucune perte ni double comptabilisation	Idempotence, preuve, journalisation et réconciliation obligatoires
Séparation stricte des zones	Borne, monétique, intégration, applicative et administration isolées
Disponibilité contrôlée	Mode dégradé sans prise de risque financier
Gestion de l'argent	Jamais d'acceptation d'espèces sans chaîne de preuve suffisante

10.2 Architecture fonctionnelle de référence

Zone	Contenu
Zone Borne	IHM kiosque, scanner, lecteur de carte EMV, PIN pad, biométrie, imprimante de reçus, imprimante de cartes EMV
Zone Monétique	Switch monétique, PIN pad certifié PCI PTS, gestion des cryptogrammes
Zone Intégration	API Gateway / WAF, API Management, connecteurs CBS, CRM, GED, AML/KYC
Zone Applicative	Micro-services : dépôts, KYC, card printer, notifications, AML
Zone Administration	Ops / Admin / Support via API Gateway / WAF — IAM, tableaux de bord NOC

Deux familles de flux traversent ces zones :

• flux critiques (monétique) — autorisations carte, PIN, cryptogrammes, isolés sur un VLAN dédié;
• flux standards (métier) — consultation, KYC, documents, notifications, acheminés via l'API Gateway.

Le catalogue détaillé des micro-services figure en annexe A.

---

11. SOP-006 — ARCHITECTURE ET ENVIRONNEMENTS

Chaque solution doit distinguer autant que nécessaire :

Environnement de développement

Utilisé pour développer et expérimenter.

Environnement de test

Utilisé pour les validations, avec bornes ou simulateurs de périphériques.

Environnement de production

Utilisé par les clients réels de la banque.

Les données réelles de carte, les données biométriques et les données de comptes ne doivent pas être utilisées dans un environnement de développement ou de test sans justification, contrôles et autorisations appropriés. Les données d'authentification sensibles (SAD) ne doivent jamais y être reproduites.

11.1 Règles d'architecture

• chaque micro-service expose une API REST / OpenAPI 3.x indépendante;
• déploiement containerisé (Docker / Kubernetes);
• isolation des pannes : un service défaillant ne bloque pas les autres;
• VLAN dédié pour le flux monétique;
• accès administration exclusivement via API Gateway / WAF;
• versioning sémantique des API.

---

12. SOP-007 — DÉVELOPPEMENT ET CONFIGURATION

Avant développement

• exigences approuvées;
• architecture validée;
• backlog défini;
• critères d'acceptation définis;
• dépendances identifiées (matériel, certifications, accès aux systèmes du client).

Pendant développement

• contrôle de version;
• revue de code obligatoire, minimum une approbation;
• tests automatisés (unitaires, intégration, bout en bout);
• SAST, DAST et SCA intégrés dans la CI/CD;
• documentation;
• gestion des secrets et des clés;
• gestion des accès;
• suivi des anomalies.

Avant livraison

• code revu;
• tests réalisés;
• SBOM généré pour la release;
• anomalies critiques résolues;
• documentation mise à jour;
• stratégie de déploiement progressif définie (canary puis blue/green).

---

13. SOP-008 — INTÉGRATION DES DONNÉES ET DES SYSTÈMES

Étapes

• Identifier les sources et les systèmes cibles.
• Définir les données nécessaires.
• Définir le mapping.
• Définir les transformations et les formats.
• Définir les règles d'idempotence et de rejeu.
• Effectuer les tests.
• Valider les résultats.
• Effectuer la migration lorsque nécessaire.
• Réconcilier les données.
• Documenter les résultats.

Contrôles

La migration et les échanges doivent vérifier notamment :

• nombre d'enregistrements et de transactions;
• champs obligatoires;
• formats;
• doublons;
• valeurs invalides;
• relations;
• intégrité;
• équilibre comptable après réconciliation.

13.1 Protocoles et formats d'échange

Flux	Destination	Format
ISO 8583	Switch monétique	Binaire
REST / SOAP	CBS, CRM, GED	JSON / XML
ISO 20022	SI cible (paiements)	XML

La couche passerelle impose : mTLS, OAuth2/OIDC, anti-DDoS, quotas, audit et contrats d'API publiés en OpenAPI.

Préconisation : privilégier ISO 20022 dès que le SI cible le supporte (conformité BCEAO — SICA-UEMOA pour la compensation retail, STAR-UEMOA pour le règlement RTGS).

---

14. SOP-009 — MATÉRIEL ET PÉRIPHÉRIQUES CERTIFIÉS

Tout périphérique embarqué doit être documenté et certifié avant intégration.

Fiche périphérique

Chaque périphérique doit préciser :

• fonction;
• modèle et fabricant;
• version de firmware;
• certifications (EMV L1/L2, PCI PTS, FBI PIV, ICAO);
• micro-service pilote;
• protocole et pilote logiciel;
• données manipulées;
• consommables et stocks associés;
• limites connues;
• mode dégradé en cas de panne;
• procédure de maintenance;
• méthode de supervision.

Périphériques critiques

Périphérique	Spécification
Module de dépôt d'espèces	Paramétrage des coupures XOF, détection de fraude BCEAO, 5 cassettes minimum, recycleur de billets
Lecteur de chèques	Reconnaissance MICR/OCR, scan recto-verso, validation montant/bénéficiaire
Écran tactile	Minimum 19", capacitif, luminosité ≥ 500 nits, ratio 16:9
Clavier PIN	Certifié PCI PTS, chiffrement AES-256 de bout en bout, tamper-proof
Lecteur de carte EMV	Level 1 & 2, puce + piste magnétique, NFC/RFID contactless
Scanner de documents	Résolution ≥ 300 DPI, A4, OCR intégré, MRZ passeport/CNI, NFC chip ICAO
Capteurs biométriques	Empreintes digitales certifiées FBI PIV, reconnaissance faciale, liveness detection
Imprimantes reçus & documents	Thermique 80 mm (reçus), A4 laser (contrats/justificatifs), gestion papier intelligente
Imprimante cartes EMV	Personnalisation EMV complète : gravure puce, encodage piste, impression recto/verso, hologramme, gestion du stock de cartes brutes, audit d'émission

Validation matérielle

Les tests doivent inclure, selon le cas :

• cas nominaux;
• consommable absent ou épuisé;
• bourrage, billet ou chèque non reconnu;
• document d'identité illisible ou falsifié;
• échec de capture biométrique et détection de liveness;
• coupure électrique en cours d'opération;
• perte de connectivité en cours d'opération;
• tentative d'ouverture ou de vandalisme;
• retrait du périphérique pendant une session;
• comportement du parcours lorsque le périphérique est hors service.

Un périphérique ne doit pas être considéré comme validé uniquement parce qu'il fonctionne dans les conditions nominales.

---

15. SOP-010 — TESTS

Niveaux de test

Tests unitaires

Validation des composants individuels.

Tests d'intégration

Validation des interactions entre composants, y compris CBS, switch monétique et moteurs AML/KYC.

Tests fonctionnels

Validation des exigences et des parcours borne.

Tests de sécurité

Validation des accès, permissions, chiffrement et protections; tests d'intrusion.

Tests de performance

Validation du comportement sous charge et en heure de pointe.

Tests de résilience

Validation du mode dégradé, des reprises et de la réconciliation; chaos engineering ciblé.

Tests matériels

Validation des périphériques en conditions réelles d'exploitation.

UAT

Le client valide que la solution répond aux besoins métier définis.

---

16. SOP-011 — VALIDATION DES OPÉRATIONS D'ESPÈCES ET DE CHÈQUES

Pour les parcours à impact financier, ajouter notamment :

• validation du parcours nominal de dépôt;
• validation du comptage et de la détection de fraude;
• validation des coupures XOF et du recyclage;
• validation des cassettes et de la collecte;
• validation de la lecture MICR/OCR des chèques;
• validation des écritures transmises au CBS;
• validation de l'idempotence et de l'absence de double comptabilisation;
• validation des reçus et des preuves;
• validation de la réconciliation;
• tests de disponibilité et de reprise;
• formation des équipes d'exploitation;
• procédure d'urgence et de contestation client.

Parcours nominal de dépôt d'espèces

Étape	Action	Détail
1	Authentification	Carte / PIN ou biométrie
2	Sélection	Type de dépôt et insertion des espèces
3	Traitement	Comptage et détection de fraude
4	Intégration	Ordre transmis au CBS
5	Confirmation	Écriture comptable différée
6	Clôture	Reçu et restitution de la carte

Gestion des incidents du parcours

Incident	Comportement attendu	Criticité
Erreur de comptage avant écriture CBS	Ne pas promettre un crédit immédiat — journaliser l'incident	Haute
Coupure électrique	UPS : sécurisation de l'état, restitution de la carte, arrêt propre	Haute
Indisponibilité du CBS	Suspension du parcours, aucune écriture financière, conservation de l'état	Haute
Indisponibilité du switch monétique	Désactivation des opérations carte/PIN uniquement; les autres fonctions sont maintenues	Moyenne
Périphérique critique défaillant	Mise hors service ciblée du parcours; la borne reste utilisable pour les autres services	Faible

Les scénarios critiques doivent être identifiés avant le Go-Live.

---

17. SOP-012 — VALIDATION DES PARCOURS LIBRE-SERVICE

Pour les parcours client :

• authentification multicanal (carte/PIN, QR code, NFC/RFID, biométrie);
• consultation de compte et historique;
• impression du relevé simplifié;
• paiement de factures et de services tiers;
• consentements;
• parcours utilisateur et nombre d'étapes;
• gestion des erreurs;
• confidentialité à l'écran;
• accessibilité (WCAG 2.2 AA, contraste 4.5:1, polices ≥ 16 px, clavier virtuel, assistance vocale);
• mode kiosque verrouillé;
• timeout de session et sécurisation automatique;
• téléassistance et escalade;
• comportement en mode dégradé.

Parcours de consultation de compte

Étape	Traitement	Détail
1	Authentification	Carte/PIN ou NFC, validation IAM
2	Requête CBS	Via API Gateway, REST / SOAP
3	Affichage	Solde et 10 dernières transactions
4	Impression	Relevé simplifié, imprimante thermique
5	Mode dégradé	Consultation limitée si le CBS est indisponible

Lecture seule → risque minimal : aucune écriture comptable n'est produite.

---

18. SOP-013 — VALIDATION KYC, AML ET ÉMISSION DE CARTES

Valider notamment :

• capture documentaire et biométrique;
• qualité des images et OCR;
• détection de falsification;
• appels aux moteurs AML/KYC (sanctions, PEP, scoring de risque);
• arbre de décision et traitement des issues;
• création du dossier CRM et du compte CBS;
• personnalisation et émission de la carte EMV;
• gestion du stock de cartes brutes et audit d'émission;
• archivage GED;
• traçabilité et horodatage;
• conservation des preuves;
• exigences spécifiques du client et du régulateur.

18.1 Chaîne de capture

Étape	Activité	Détail
1	Initialisation	Présélection de l'offre, consentement explicite du client
2	Capture documentaire	Scan de la carte d'identité / du passeport via scanner 300 DPI
3	Capture biométrique	Photo du visage et empreintes digitales (capteur certifié FBI PIV)
4	Contrôle qualité	Vérification de l'image, OCR, détection de falsification
5	Vérification externe	Appel des moteurs AML/KYC — sanctions, PEP, faux documents
6	Création du dossier	Enregistrement CRM et création du compte CBS si conforme

18.2 Arbre de décision KYC

Issue de la vérification	Traitement
Conforme	Création du compte CBS, édition du contrat, remise de la carte (si disponible)
Suspicion	Mise en attente, escalade back-office, notification au conseiller
Échec	Refus motivé et orientation vers un conseiller en agence

Toute sortie utilisée à des fins réglementaires ou contractuelles doit disposer d'un processus de validation adapté à son utilisation prévue.

---

19. SOP-014 — SECURITY & PRIVACY GATE

Avant production, effectuer une revue de sécurité.

Checklist

• [ ] Authentification configurée (OAuth2/OIDC, MFA)
• [ ] Autorisations et rôles vérifiés
• [ ] Comptes administrateurs contrôlés
• [ ] Secrets et clés protégés, rotation définie
• [ ] Chiffrement vérifié (AES-256 minimum, RSA 2048+)
• [ ] PIN pad certifié PCI PTS en place
• [ ] Aucun stockage des SAD (pistes complètes, CVV) après autorisation
• [ ] VLAN monétique isolé et contrôles réseau vérifiés
• [ ] Logs et journalisation monétique configurés, SIEM raccordé
• [ ] Données sensibles et biométriques identifiées, templates chiffrés
• [ ] Accès minimisés
• [ ] Sauvegardes configurées
• [ ] Procédure d'incident disponible
• [ ] Fournisseurs externes documentés
• [ ] Flux de données documentés
• [ ] Vulnérabilités suivies (inventaire des actifs, CVE, délais basés CVSS)
• [ ] Pentest réalisé et anomalies critiques traitées

Référentiels applicables

• ISO/IEC 27001 — management de la sécurité de l'information;
• PCI DSS v4.0.1 — sécurité des données de porteurs de cartes;
• PCI PTS — certification des PIN pads;
• EMV Level 1 & 2 — lecture et personnalisation des cartes;
• RGPD et réglementation locale — minimisation, limitation des finalités, rétention contrôlée;
• WCAG 2.2 AA et EAA — accessibilité des terminaux libre-service;
• ISO/IEC 25010 — qualité du produit logiciel;
• exigences BCEAO et FATF — conformité régionale, AML/KYC, coupures XOF.

Les exigences légales et réglementaires applicables doivent être identifiées selon la juridiction du client.

---

20. SOP-015 — GO-LIVE READINESS

Un Go-Live ne doit être autorisé que lorsque les conditions définies sont satisfaites.

Go-Live Checklist

Produit

• [ ] Fonctionnalités terminées
• [ ] Tests terminés
• [ ] Tests matériels terminés
• [ ] UAT approuvé

Technique

• [ ] Production prête
• [ ] Bornes installées et raccordées
• [ ] Monitoring actif
• [ ] Sauvegarde vérifiée
• [ ] Rollback défini

Sécurité

• [ ] Accès vérifiés
• [ ] Sécurité validée
• [ ] Données validées
• [ ] Conformité monétique confirmée

Client

• [ ] Formation réalisée (exploitation, support, collecte)
• [ ] Documentation remise
• [ ] Procédure de réconciliation confirmée
• [ ] Contacts support confirmés
• [ ] Approbation Go-Live obtenue

---

21. SOP-016 — DÉPLOIEMENT

Le déploiement doit suivre un plan documenté.

Plan

• Vérification pré-déploiement.
• Sauvegarde.
• Déploiement logiciel (canary puis blue/green).
• Installation et raccordement des bornes.
• Migration éventuelle.
• Vérifications techniques et tests périphériques sur site.
• Smoke tests.
• Validation fonctionnelle.
• Activation progressive des services.
• Surveillance.
• Confirmation du Go-Live.

Rollback

Chaque déploiement critique doit définir :

• condition de rollback;
• responsable;
• procédure;
• durée estimée;
• données et transactions concernées;
• traitement des opérations en cours;
• communication au client.

---

22. SOP-017 — HYPERCARE

Après le Go-Live, une période d'hypercare est mise en place lorsque nécessaire.

Pendant cette période :

• monitoring renforcé du parc;
• traitement prioritaire des incidents;
• suivi quotidien des réconciliations;
• présence terrain renforcée les premiers jours;
• collecte du feedback;
• analyse des erreurs et des abandons de parcours;
• suivi de l'adoption;
• correction rapide des problèmes critiques.

À la fin de l'hypercare, le projet est transféré aux opérations/support.

---

23. SOP-018 — TRANSFERT AU SUPPORT

Le transfert doit comprendre :

• architecture;
• configuration;
• inventaire du parc et des périphériques;
• documentation;
• procédures d'exploitation et de maintenance;
• procédure de collecte et de réapprovisionnement des consommables;
• contacts;
• accès;
• monitoring;
• incidents connus;
• limitations connues;
• procédures de résolution;
• SLA applicables.

Le support doit savoir : quoi surveiller, quoi faire lorsqu'une alerte apparaît et quand escalader.

---

24. SOP-019 — GESTION DES INCIDENTS

Classification

P1 — Critique

Impact majeur sur le service : écart de caisse, indisponibilité du parc, incident de sécurité.

P2 — Élevé

Impact important mais solution ou contournement possible : borne isolée hors service, périphérique critique en panne.

P3 — Normal

Impact limité : dégradation d'un service secondaire.

P4 — Faible

Question, amélioration ou problème mineur.

Chaque contrat client doit définir les délais et obligations applicables.

Processus

Détection → Qualification → Contention → Résolution → Validation → Communication → Post-mortem

Tout incident à impact financier donne lieu à une réconciliation documentée avant clôture.

---

25. SOP-020 — MONITORING

Surveiller selon la solution :

Supervision technique

• état des périphériques;
• CPU, mémoire, disque, température;
• connectivité et latence réseau;
• niveaux de consommables (papier, cartes brutes, cassettes).

Supervision transactionnelle

• taux de succès / échec par service;
• volumes par type de transaction;
• temps de réponse de bout en bout;
• écarts de réconciliation.

Supervision de sécurité

• SIEM et corrélation d'événements;
• détection d'intrusion (IDS/IPS);
• tentatives anormales et fraude;
• alertes anti-vandalisme et vidéosurveillance.

Les alertes sont émises en temps réel vers le NOC et les tableaux de bord Ops / Admin / Support.

---

26. SOP-021 — GESTION DU PARC ET DES VERSIONS

Pour chaque borne et chaque périphérique :

• identifiant et site;
• modèle;
• fournisseur;
• version logicielle et firmware;
• date de mise en service;
• services activés;
• consommables;
• interventions;
• limites;
• métriques;
• dépendances.

Lorsqu'un firmware ou un composant matériel change, effectuer une analyse d'impact. Une nouvelle version d'un firmware ou d'un périphérique ne doit pas être considérée comme automatiquement équivalente à l'ancienne : une revalidation des parcours concernés est requise.

---

27. SOP-022 — GESTION DES FOURNISSEURS

Documenter les fournisseurs critiques :

• cloud et hébergement;
• fabricants de bornes et de périphériques;
• switch monétique;
• éditeur du CBS;
• moteurs AML/KYC;
• fournisseurs de cartes brutes et de consommables;
• APIs et logiciels;
• sécurité;
• plateforme de communication (SMS, email, push);
• maintenance terrain.

Pour chaque fournisseur :

• service fourni;
• données concernées;
• dépendance;
• criticité;
• contrat;
• disponibilité;
• délais d'intervention;
• procédure en cas d'indisponibilité.

---

28. SOP-023 — GESTION DES ACCÈS

Principe général : Chaque utilisateur doit disposer uniquement des accès nécessaires à son rôle.

Processus : Demande → Validation → Création → Vérification → Monitoring → Révocation

• les accès doivent être retirés lorsqu'ils ne sont plus nécessaires;
• les comptes privilégiés doivent bénéficier de contrôles renforcés;
• les accès physiques aux bornes et aux cassettes suivent le même processus que les accès logiques;
• toute action d'administration est journalisée dans une piste d'audit.

---

29. SOP-024 — RÉSILIENCE, SAUVEGARDE ET REPRISE

Chaque solution critique doit définir :

• quelles données sont sauvegardées;
• fréquence;
• durée de conservation;
• emplacement;
• responsable;
• méthode de restauration;
• objectifs de récupération (RPO/RTO);
• procédure de test.

Une sauvegarde qui n'a jamais été restaurée/testée ne doit pas être considérée comme pleinement validée.

29.1 Traitement des pannes

Chaîne de traitement : détection → isolation ciblée → dégradation maîtrisée → journalisation → reprise et réconciliation.

Mécanisme	Description
Mode dégradé automatique	Détection de la panne → isolation → dégradation ciblée
UPS et sécurisation de l'état	Coupure électrique → arrêt propre, restitution de la carte
Réconciliation automatique	Retour à la normale → synchronisation CBS, contrôle d'intégrité
Isolation des pannes	Service défaillant isolé, autres services maintenus
Journalisation systématique	Piste d'audit complète pour l'analyse post-incident et la preuve
Tests de résilience périodiques	Tests d'intrusion et chaos engineering ciblé

Disponibilité contrôlée = mode dégradé sans prise de risque financier.

---

30. SOP-025 — AMÉLIORATION CONTINUE

Après livraison :

• analyser les incidents;
• analyser l'utilisation du parc;
• recueillir le feedback des clients et des agences;
• mesurer les KPI;
• identifier les améliorations;
• prioriser;
• développer;
• tester;
• déployer;
• mesurer le résultat.

La plateforme doit être considérée comme un produit vivant et non comme un projet terminé au Go-Live.

---

31. KPI QUBITDT

KPI projet

• délai prévu vs réel;
• budget prévu vs réel;
• nombre de changements;
• nombre d'anomalies;
• nombre d'incidents post-Go-Live;
• délai moyen de résolution.

KPI produit et parc

• bornes en service;
• disponibilité du parc;
• taux de panne par périphérique;
• adoption et utilisateurs actifs;
• utilisation des services;
• performance;
• taux d'erreur.

KPI monétique et financiers

• taux de succès des transactions;
• volumes par type de transaction;
• écarts de caisse;
• délai de réconciliation;
• incidents à impact financier;
• transactions rejetées par le switch.

KPI client

• satisfaction;
• tickets support;
• taux d'abandon de parcours;
• renouvellement;
• utilisation;
• feedback;
• valeur créée.

---

32. RACI STANDARD

Activité	qubitdt	Banque	IT banque	Métier banque
Discovery	R	A/R	C	C
Requirements	R	A	C	R
Architecture	R	C	C	C
Développement	R	I	C	I
Intégrations (CBS, switch)	R	A	R	C
Installation des bornes	R	A	C	C
UAT	C	A	C	R
Go-Live	R	A	R	C
Formation	R	C	C	R
Exploitation du parc	R	A	C	C

R = Responsible A = Accountable C = Consulted I = Informed

Ce RACI doit être adapté à chaque contrat.

---

33. DOCUMENTS À PRODUIRE PAR PROJET

Chaque projet devrait posséder un dossier structuré.

01 — Commercial

• proposition;
• contrat;
• périmètre.

02 — Discovery

• notes;
• processus;
• besoins;
• inventaire des sites.

03 — Requirements

• exigences;
• user stories;
• critères d'acceptation.

04 — Architecture

• architecture;
• diagrammes;
• intégrations;
• catalogue des micro-services.

05 — Data

• inventaire;
• mapping;
• migration;
• règles de réconciliation.

06 — Matériel

• fiches périphériques;
• certifications;
• firmwares;
• plan d'installation;
• consommables.

07 — Testing

• plan de test;
• résultats;
• anomalies;
• tests matériels et de résilience;
• UAT.

08 — Deployment

• plan;
• Go-Live checklist;
• rollback.

09 — Operations

• runbook;
• monitoring;
• support;
• procédure de collecte et de maintenance.

10 — Closure

• approbation finale;
• lessons learned;
• transfert.

---

34. CRITÈRES DE SORTIE DES PHASES

Une phase ne doit passer à la suivante que si ses critères de sortie sont satisfaits.

Discovery → Requirements

Le problème, les utilisateurs, les sites et le périmètre sont suffisamment compris.

Requirements → Development

Les exigences critiques sont approuvées.

Development → Testing

La version est suffisamment stable pour être testée et les périphériques sont disponibles.

Testing → UAT

Les tests internes requis, y compris matériels et de résilience, sont terminés.

UAT → Go-Live

Le client a approuvé les critères définis et la conformité monétique est confirmée.

Go-Live → Hypercare

La solution est opérationnelle, les bornes sont en service et le monitoring est actif.

Hypercare → Support

La solution est suffisamment stable pour entrer dans le fonctionnement normal et les réconciliations sont sans écart persistant.

---

35. CHECKLIST FINALE DU CHEF DE PROJET

Avant de clôturer un projet :

• [ ] Périmètre livré
• [ ] Exigences validées
• [ ] Tests terminés
• [ ] Tests matériels et de résilience terminés
• [ ] UAT approuvé
• [ ] Sécurité validée
• [ ] Conformité monétique validée
• [ ] Données validées
• [ ] Réconciliation sans écart
• [ ] Documentation remise
• [ ] Formation effectuée
• [ ] Go-Live effectué
• [ ] Support informé
• [ ] Monitoring actif
• [ ] Incidents critiques résolus
• [ ] Contrat/SLA documenté
• [ ] Lessons learned réalisées
• [ ] Approbation de clôture obtenue

---

36. PRINCIPE DIRECTEUR QUBITDT

Le principe central du processus est :

Comprendre avant de construire. Documenter avant de déployer. Tester avant de livrer. Valider avant de mettre en production. Surveiller après le Go-Live. Améliorer continuellement.

Pour les solutions bancaires libre-service, un principe supplémentaire s'applique :

La performance technique ne suffit pas : la sécurité, la conformité, la preuve de chaque opération, la disponibilité contrôlée et l'absence de risque financier doivent également être prises en compte.

---

37. ANNEXE — TEMPLATE FICHE PROJET

Nom du projet : Client : Produit : ☐ Bornes libre-service ☐ Émission de cartes EMV ☐ KYC / Ouverture de compte ☐ Autre Responsable qubitdt : Responsable client : Date de début : Date prévue de Go-Live : Objectif : Nombre de bornes et sites : Services activés : Périphériques : Données utilisées : Intégrations : Niveau de criticité : Exigences particulières : Risques principaux : KPI de succès : SLA : Statut :

---

38. ANNEXE — TEMPLATE GO-LIVE APPROVAL

Projet : Client : Date :

Les parties confirment que les critères définis pour le Go-Live ont été évalués.

Validation

Produit : ☐ Technique : ☐ Matériel : ☐ Données : ☐ Sécurité : ☐ Monétique : ☐ UAT : ☐ Formation : ☐ Support : ☐ Monitoring : ☐ Rollback : ☐

Décision : ☐ Go-Live approuvé ☐ Go-Live reporté

Commentaires : Responsable qubitdt : Responsable client : Date :

---

39. ANNEXE — TEMPLATE INCIDENT

Numéro : Date/heure : Client : Solution : Borne / site : Sévérité : Description : Impact : Impact financier : Détection : Cause : Actions immédiates : Résolution : Réconciliation : Validation : Communication client : Action préventive : Responsable : Date de clôture :

---

40. ANNEXE A — CATALOGUE DES MICRO-SERVICES

Architecture distribuée : 14 domaines fonctionnels indépendants. Chaque micro-service expose une API REST / OpenAPI 3.x indépendante et est déployé en conteneur (Docker / Kubernetes).

Micro-service	Responsabilités
Card Printer Management	Impression EMV, personnalisation carte, file d'attente, statut imprimante, retry automatique
Cash Management	Recycleur, comptage, cassettes, détection de fraude, réconciliation, audit des coupures XOF
Phone Kiosk & Call Center	VoIP intégré, agent management, escalade, file d'attente, SLA, enregistrement des appels
Camera Management	Vidéosurveillance, anti-vandalisme, liveness detection, capture KYC, archivage GED
OCR / ID & Passport Reader	Scan CNI/passeport, OCR MRZ, NFC chip, validation ICAO, anti-falsification, 300 DPI
Check Acceptor	Lecture MICR, scan recto-verso, OCR montant/bénéficiaire, validation, archivage CBS
QR Scanner Management	Lecture QR/barcode, paiement de facture, authentification sans carte, tokenisation, compatibilité UEMOA
POS Server Management	ISO 8583, routage switch, gestion des sessions, clés cryptographiques, failover automatique
Printer Management	Thermique 80 mm (reçus), A4 laser (contrats), gestion papier, statut, file d'impression, retry
Biometric Management	Empreintes FBI PIV, reconnaissance faciale, liveness, templates chiffrés, RGPD, enrôlement
NFC / Card Reader Mgmt	EMV L1/L2, puce + piste, NFC/RFID, PIN pad PCI PTS, tokenisation, contactless
AML / KYC Engine	Sanctions, PEP screening, scoring de risque, détection de faux documents, conformité BCEAO/FATF
Notification & Comm	SMS / email / push, alertes temps réel, confirmations transactionnelles, escalades NOC
Session & IAM	Authentification multicanal, OAuth2/OIDC, MFA, rôles, timeout, audit trail, consentement RGPD

---

41. ANNEXE B — INTEROPÉRABILITÉ ET DÉPENDANCES EXTERNES

Système externe	Protocole	Usage
Switch monétique	ISO 8583	Autorisation des transactions carte (ex. Amplitude, PowerCard)
Core Banking System (CBS)	REST / SOAP	Écritures comptables, soldes
CRM	REST	Gestion de la relation client
GED	REST	Archivage des documents KYC et des contrats EMV
Moteurs AML/KYC	REST / SOAP	Vérification de conformité — BCEAO / FATF
Plateforme de communication	REST	SMS, email, notifications push

Note BCEAO : plateforme régionale basée sur ISO 20022 — SICA-UEMOA (compensation retail) et STAR-UEMOA (règlement RTGS). Les formats ISO 20022 sont activés dès que le SI du client les supporte.

---

42. ANNEXE C — GLOSSAIRE

Terme	Définition
AML	Anti-Money Laundering — lutte contre le blanchiment
BCEAO	Banque Centrale des États de l'Afrique de l'Ouest
CBS	Core Banking System — cœur bancaire
GED	Gestion électronique des documents
IAM	Identity and Access Management
KYC	Know Your Customer — connaissance client
MICR	Magnetic Ink Character Recognition (lecture des chèques)
MRZ	Machine Readable Zone d'un document d'identité
NOC	Network Operations Center
PEP	Personne politiquement exposée
RPO / RTO	Objectifs de perte de données et de délai de reprise
SAD	Sensitive Authentication Data
SBOM	Software Bill of Materials
SAST / DAST / SCA	Analyses statique, dynamique et de composants
SICA-UEMOA	Système interbancaire de compensation automatisé de l'UEMOA
SIEM	Security Information and Event Management
STAR-UEMOA	Système de transfert automatisé et de règlement de l'UEMOA
UEMOA	Union économique et monétaire ouest-africaine
XOF	Franc CFA (UEMOA)

---

43. VERSIONNAGE DU MANUEL

Toute modification importante du présent manuel doit être enregistrée.

Version	Date	Modification	Responsable
1.0	À définir	Création du manuel qubitdt	Qubit Digital Technology