Cahier des charges fonctionnel et technique

Évolution de BranchCheck vers une plateforme de gestion de la performance multidomaines

Version : 1.0 — document de cadrage pour l’IT
Date : 28 août 2026
Périmètre initial : réseaux d’agences — banque, microfinance, distribution et activités comparables
Statut : proposition à valider par les métiers, la direction des risques et l’IT

---

1. Objet du cahier des charges

Le présent cahier des charges définit les besoins fonctionnels, techniques, organisationnels et de sécurité nécessaires pour faire évoluer BranchCheck, actuellement positionnée sur les inspections terrain et la conformité des réseaux d’agences, vers une plateforme multidomaine de gestion de la performance.

La solution cible devra permettre de décliner les objectifs et standards du siège, de les exécuter sur le terrain, de collecter des résultats et des preuves, de gérer les écarts, de suivre les plans d’action et de piloter la performance par agence, zone, région, processus, activité, manager et période.

L’évolution devra préserver les atouts actuels de BranchCheck : fonctionnement offline-first, checklists, photos horodatées et géolocalisées, signatures, preuves d’intégrité, planification par le risque, actions correctives, KPI, rapports PDF et IA gouvernée [1].

Principe directeur : un même moteur de référentiels, campagnes, évaluations, preuves, actions, validations et reporting doit servir l’ensemble des domaines. Les domaines ne doivent pas être développés comme des applications indépendantes.

2. Contexte et enjeux

BranchCheck dispose d’un socle adapté à la collecte et à la preuve d’exécution dans des réseaux distribués. Le besoin consiste désormais à couvrir une chaîne de performance plus large : objectifs, animation, exécution commerciale, conformité, contrôle permanent, audit, qualité, formation, remédiation et amélioration continue.

L’enjeu principal est de créer une vision commune et fiable de la performance. Une agence doit pouvoir être évaluée selon ses résultats commerciaux, son niveau de conformité, la maîtrise de ses risques, la qualité de son service, le niveau de ses compétences et sa capacité à exécuter les plans d’amélioration.

Le projet devra également éviter trois risques : la multiplication de fichiers et outils parallèles, l’absence de traçabilité entre un écart et sa résolution, et la production de scores non explicables ou non comparables.

3. Objectifs du projet

Référence	Objectif
OBJ-01	Centraliser les référentiels, objectifs, contrôles, campagnes, audits, formations et plans d’action.
OBJ-02	Permettre l’exécution terrain en mode connecté et hors connexion.
OBJ-03	Relier chaque résultat important à une source, une preuve, un responsable et une validation.
OBJ-04	Déployer un pilotage multidomaine par agence, zone, région, activité, rôle et période.
OBJ-05	Automatiser la planification, les notifications, les relances et les escalades.
OBJ-06	Exploiter les écarts pour déclencher des actions de remédiation, de coaching ou de formation.
OBJ-07	Garantir une gouvernance robuste des données, des accès, des workflows et de l’IA.
OBJ-08	Fournir une architecture ouverte permettant les intégrations avec les systèmes existants.

4. Périmètre fonctionnel

4.1 Périmètre inclus

Le périmètre comprend le moteur multidomaine commun et les sept domaines suivants : performance commerciale, conformité, contrôle permanent, audit, animation du réseau, formation et compétences, qualité et amélioration continue.

Le périmètre comprend également la gestion des organisations et utilisateurs, les référentiels, les workflows, la gestion documentaire et probatoire, les tableaux de bord, les notifications, les API, les exports, la mobilité offline-first et l’administration de la solution.

4.2 Périmètre exclu de la première version

La solution ne devra pas chercher à remplacer immédiatement un CRM complet, un core banking, un ERP, un logiciel comptable, un LMS industriel ou un outil spécialisé de gestion de projet. Elle devra s’interfacer avec ces systèmes lorsque cela est nécessaire.

La paie, la comptabilité, la gestion détaillée des transactions clients et la décision de crédit sont hors périmètre initial, sauf besoin spécifique validé dans un lot ultérieur.

4.3 Principes de priorisation

La première version devra privilégier les domaines les plus proches du socle existant : conformité, contrôle permanent, audit et qualité. Les fonctionnalités commerciales, d’animation et de formation devront être conçues dès le départ dans le modèle de données, mais pourront être livrées par lots successifs.

Priorité	Domaine	Justification
P1	Moteur commun, conformité, contrôle permanent, qualité	Forte réutilisation du socle actuel et valeur immédiate sur la maîtrise des risques.
P1	Actions, KPI, workflow, reporting	Fonctions transverses indispensables à tous les domaines.
P2	Audit	Extension naturelle du contrôle et de la gestion des constats.
P2	Animation du réseau	Permet de transformer les orientations en campagnes exécutables.
P2	Performance commerciale	À connecter aux sources commerciales existantes plutôt qu’à remplacer un CRM.
P3	Formation et compétences	À alimenter par les écarts et les besoins identifiés dans les autres domaines.
P3	IA avancée et analyses prédictives	À déployer progressivement après sécurisation des données et des règles métier.

5. Utilisateurs et rôles

La solution devra appliquer un contrôle d’accès par rôle, périmètre organisationnel, domaine et niveau de confidentialité. Les rôles ci-dessous constituent le modèle initial à confirmer lors des ateliers.

Rôle	Responsabilités principales
Administrateur plateforme	Paramétrage global, sécurité, utilisateurs, intégrations et supervision technique.
Administrateur métier	Gestion des référentiels, modèles, campagnes, scores et règles de workflow.
Direction générale	Consultation des tableaux de bord consolidés et arbitrage des plans prioritaires.
Responsable réseau/région	Pilotage des agences, campagnes, objectifs, alertes et plans d’amélioration.
Directeur ou responsable d’agence	Exécution locale, réponse aux constats, validation et suivi des engagements.
Contrôleur	Réalisation des contrôles, inspections, preuves, constats et recommandations.
Auditeur	Préparation des missions, tests, constats, rapports et suivi indépendant.
Responsable conformité/risques	Référentiels réglementaires, plans de contrôle, incidents et remédiation.
Responsable qualité	Standards, non-conformités, réclamations, causes racines et amélioration continue.
Responsable formation	Catalogue, parcours, compétences, habilitations et évaluations.
Collaborateur	Consultation de ses objectifs, tâches, formations, actions et résultats autorisés.
Auditeur de la plateforme	Accès en lecture aux journaux, preuves, changements et historiques.

La séparation des tâches devra interdire, sauf dérogation tracée, qu’une même personne crée, réalise, valide et clôture seule un contrôle ou une action critique.

6. Modèle fonctionnel commun

6.1 Référentiels

Le système devra permettre de créer, modifier, versionner, publier, archiver et dater les référentiels. Un référentiel pourra être associé à un domaine, un processus, une entité, une zone géographique, un type d’agence, une population ou un niveau de risque.

Chaque exigence devra pouvoir comporter une description, un propriétaire, une fréquence, une criticité, une règle de contrôle, une preuve attendue, une date d’effet et une relation vers une procédure ou un document.

6.2 Campagnes et plans

Une campagne devra définir son objectif, son périmètre, sa période, les populations concernées, les tâches attendues, les critères de réussite, les preuves et les responsables. Elle pourra être planifiée ponctuellement ou récurrente.

Un plan de performance devra regrouper objectifs, indicateurs, contrôles, actions, formations et commentaires. Il devra être rattaché à une agence, un manager, un processus, une activité ou un collaborateur.

6.3 Évaluations et scores

Le système devra gérer des questions, critères, réponses, valeurs numériques, choix pondérés, commentaires, pièces jointes et preuves. Les scores devront être configurables par modèle et explicables jusqu’à la donnée source.

Il faudra distinguer explicitement une valeur nulle, une donnée absente, une donnée non applicable et une donnée non conforme. Les agrégations devront pouvoir être calculées par période, périmètre, domaine, niveau hiérarchique et type d’objet.

6.4 Actions et remédiation

Toute non-conformité, recommandation, incident, écart de performance ou besoin de formation devra pouvoir générer une action. Une action comportera au minimum un responsable, une échéance, une priorité, une criticité, une cause ou catégorie, un statut, une preuve attendue et une validation finale.

Le système devra gérer les relances, les retards, les escalades, les demandes de prolongation, les rejets de preuve et la clôture conditionnelle. La clôture d’une action critique devra nécessiter une validation distincte de sa réalisation.

6.5 Workflow

Les workflows devront être configurables sans développement pour les cas courants. Les étapes minimales sont : brouillon, soumis, en revue, validé, rejeté, en cours, en retard, clôturé et archivé.

Chaque transition devra pouvoir exiger un rôle, une justification, une preuve, un commentaire ou une signature. Toutes les transitions devront être historisées.

7. Exigences fonctionnelles par domaine

7.1 Performance commerciale

ID	Exigence	Priorité
COM-01	Décliner des objectifs par réseau, région, agence, équipe ou collaborateur.	P2
COM-02	Importer ou synchroniser les résultats commerciaux depuis les systèmes sources.	P2
COM-03	Suivre activités, visites, prospects, opportunités, conversions et engagements.	P2
COM-04	Organiser des campagnes commerciales, challenges et actions d’animation.	P2
COM-05	Comparer résultats, activités réalisées et qualité d’exécution.	P2
COM-06	Déclencher coaching, action corrective ou formation à partir d’un écart identifié.	P2

La plateforme devra rester complémentaire d’un CRM. Elle devra privilégier le pilotage de l’exécution, des campagnes, des visites, des engagements et des actions plutôt que la gestion exhaustive de la relation client.

7.2 Conformité

ID	Exigence	Priorité
CON-01	Gérer des exigences réglementaires et internes versionnées.	P1
CON-02	Associer chaque exigence à des contrôles, une fréquence, une criticité et une preuve attendue.	P1
CON-03	Produire un score et une cartographie de conformité par périmètre.	P1
CON-04	Gérer les écarts, plans de remédiation, validations et clôtures.	P1
CON-05	Conserver l’historique des versions et des décisions.	P1
CON-06	Générer des dossiers de preuve exportables et partageables de manière contrôlée.	P1

7.3 Contrôle permanent

ID	Exigence	Priorité
CP-01	Définir un plan de contrôle par processus, risque, entité et fréquence.	P1
CP-02	Programmer des contrôles de niveau 1 et de niveau 2.	P1
CP-03	Gérer l’échantillonnage et documenter la méthode utilisée.	P1
CP-04	Enregistrer résultat, anomalie, incident, preuve et commentaire.	P1
CP-05	Calculer la couverture et le taux de réalisation des contrôles.	P1
CP-06	Escalader automatiquement les contrôles critiques ou en retard.	P1

7.4 Audit

ID	Exigence	Priorité
AUD-01	Créer un plan d’audit fondé sur les risques et les historiques.	P2
AUD-02	Gérer mission, périmètre, équipe, calendrier et programme de travail.	P2
AUD-03	Documenter entretiens, tests, constats, recommandations et réponses.	P2
AUD-04	Distinguer observation, recommandation, non-conformité, incident et constat critique.	P2
AUD-05	Générer un rapport d’audit avec chaîne de preuve et validations.	P2
AUD-06	Suivre les recommandations jusqu’à validation indépendante de la clôture.	P2

7.5 Animation du réseau

ID	Exigence	Priorité
ANI-01	Créer une campagne d’animation avec population cible, calendrier et objectif.	P2
ANI-02	Diffuser des consignes, supports et tâches aux agences concernées.	P2
ANI-03	Suivre réunions, visites managériales, événements et engagements.	P2
ANI-04	Gérer challenges, classements et règles de calcul configurables.	P3
ANI-05	Mesurer diffusion, réalisation, appropriation et impact de la campagne.	P2

7.6 Formation et compétences

ID	Exigence	Priorité
FOR-01	Gérer un catalogue de formations, parcours et populations cibles.	P3
FOR-02	Définir une matrice de compétences par poste, rôle ou activité.	P3
FOR-03	Suivre inscriptions, présence, évaluations, attestations et habilitations.	P3
FOR-04	Gérer dates d’expiration et recyclages obligatoires.	P3
FOR-05	Recommander une formation à partir d’un écart, d’un audit ou d’un contrôle.	P3
FOR-06	Produire un tableau de bord des compétences et habilitations.	P3

7.7 Qualité et amélioration continue

ID	Exigence	Priorité
QUA-01	Gérer standards, procédures, critères qualité et versions applicables.	P1
QUA-02	Enregistrer non-conformités, incidents, réclamations et anomalies.	P1
QUA-03	Qualifier gravité, cause, processus, récurrence et impact.	P1
QUA-04	Gérer analyses de causes racines et plans d’amélioration.	P2
QUA-05	Mesurer la baisse des écarts récurrents et l’efficacité des actions.	P2
QUA-06	Relier les résultats qualité aux campagnes, formations et objectifs.	P2

8. Tableaux de bord et indicateurs

La solution devra proposer des tableaux de bord adaptés au rôle de l’utilisateur. Les composants devront permettre filtrage, drill-down, comparaison de périodes, comparaison de périmètres, export et accès à la donnée source.

Tableau de bord	Contenu minimal
Direction	Score global, tendances, agences à risque, écarts critiques, plans en retard.
Réseau/région	Classement ou comparaison des agences, campagnes, contrôles, actions et alertes.
Agence	Objectifs, résultats, contrôles, conformité, qualité, formations et actions.
Contrôle/conformité	Couverture, taux de réalisation, écarts par criticité, remédiation et échéances.
Audit	Missions, constats, recommandations ouvertes, retards et récurrence.
Formation	Taux de complétion, compétences, habilitations expirées et besoins prioritaires.
Qualité	Non-conformités, réclamations, causes racines, récurrence et efficacité des actions.

Les KPI devront être documentés dans un dictionnaire comprenant nom, définition, formule, source, fréquence, propriétaire, périmètre, seuils, règles d’exclusion et date de validité.

9. Exigences de mobilité et de preuve

ID	Exigence	Priorité
MOB-01	Permettre la réalisation des tâches essentielles sans connexion réseau.	P1
MOB-02	Synchroniser automatiquement les données dès le retour de la connectivité.	P1
MOB-03	Gérer les conflits de synchronisation selon des règles documentées.	P1
MOB-04	Capturer photos, GPS, horodatage et signature lorsque le cas d’usage le requiert.	P1
MOB-05	Associer chaque preuve à l’objet, au point de contrôle et à l’utilisateur concerné.	P1
MOB-06	Empêcher ou signaler la modification non autorisée d’une preuve validée.	P1
MOB-07	Permettre l’export d’un dossier probatoire lisible et vérifiable.	P1
MOB-08	Supporter l’interface française, anglaise et arabe avec affichage RTL.	P2

Les règles de preuve devront préciser les métadonnées conservées, la compression, la durée de conservation, les droits d’accès, les conditions de partage et les événements qui rendent une preuve invalide ou nécessitent une nouvelle collecte.

10. Exigences techniques

10.1 Architecture

L’architecture cible devra être modulaire, documentée et compatible avec les modes SaaS, hébergement dédié et auto-hébergement déjà envisagés pour BranchCheck [1]. Les composants devront être séparables afin de permettre l’évolution indépendante du moteur métier, de la mobilité, du stockage probatoire, du reporting et des intégrations.

L’IT devra fournir un schéma d’architecture logique et physique incluant frontend, API, services métier, workers asynchrones, base de données, stockage objet, moteur de recherche éventuel, service de notifications, observabilité et sauvegardes.

10.2 API et intégrations

La plateforme devra exposer des API documentées, versionnées et sécurisées. Les intégrations prioritaires à confirmer sont l’annuaire d’entreprise, les systèmes RH, le CRM ou système commercial, les outils de formation, les outils de notification et les référentiels réglementaires.

ID	Exigence	Priorité
API-01	API REST ou équivalent documentée avec OpenAPI.	P1
API-02	Authentification forte, gestion des scopes et limitation de débit.	P1
API-03	Webhooks pour événements métier importants.	P2
API-04	Imports et exports CSV/XLSX contrôlés et journalisés.	P1
API-05	Idempotence et mécanismes de reprise pour synchronisations.	P1
API-06	Environnement sandbox pour les tests d’intégration.	P2
API-07	Journal technique et fonctionnel des échanges.	P1

10.3 Performance et disponibilité

Les objectifs définitifs devront être confirmés après dimensionnement. À titre de cible initiale, les écrans standards devront répondre en moins de trois secondes dans 95 % des cas sur un périmètre courant, hors génération de rapports lourds. Les opérations longues devront être traitées de manière asynchrone avec notification de fin.

La solution devra préserver la continuité de travail en mode offline. Les objectifs de disponibilité, de reprise après incident, de perte de données acceptable et de temps de restauration devront être contractualisés selon le mode d’hébergement.

10.4 Sécurité et confidentialité

La solution devra appliquer le principe du moindre privilège, la séparation des tâches, le chiffrement des flux, la protection des secrets, la journalisation des accès sensibles et la révocation immédiate des comptes ou sessions compromis.

Les exigences minimales sont les suivantes : authentification fédérée lorsque disponible, MFA pour les profils sensibles, RBAC et filtrage par périmètre, chiffrement en transit et au repos, sauvegardes chiffrées, tests de restauration, protection contre les attaques courantes, gestion des vulnérabilités, traçabilité des exports et contrôle des liens de partage.

Les données personnelles devront être minimisées, classifiées, exportables et supprimables selon les règles applicables. Les durées de conservation, bases légales et procédures d’effacement devront être définies avec le responsable juridique et le délégué à la protection des données.

10.5 Auditabilité

Le journal d’audit devra enregistrer au minimum l’utilisateur, la date et l’heure, l’action, l’objet concerné, l’ancienne valeur lorsque pertinente, la nouvelle valeur, le résultat, l’adresse ou contexte technique et la justification lorsqu’elle est requise.

Le journal devra être protégé contre la modification par les utilisateurs standards et exportable pour les besoins d’audit, d’enquête ou de contrôle réglementaire.

10.6 IA gouvernée

Les fonctions d’IA devront être optionnelles, clairement identifiées et soumises à validation humaine lorsque leur résultat influence un score, une décision, un constat ou une action critique. Aucun résultat généré ne devra être présenté comme une vérité non vérifiée.

Chaque appel devra pouvoir être journalisé avec le modèle, la date, l’utilisateur ou service demandeur, le type de donnée transmis, le résultat et le statut de validation. Un mécanisme de désactivation globale ou par tenant devra être disponible. Les données confidentielles ne devront pas être transmises à un service externe sans autorisation et cadre contractuel approprié.

11. Données et modèle de référence

Le modèle de données devra au minimum couvrir les entités suivantes : organisation, zone, agence, processus, activité, utilisateur, rôle, poste, objectif, indicateur, risque, exigence, référentiel, campagne, contrôle, inspection, mission d’audit, formation, compétence, incident, non-conformité, action, preuve, validation, notification et journal d’audit.

Chaque objet devra disposer d’un identifiant unique, d’un propriétaire, d’un statut, de dates de création et de modification, d’un périmètre de visibilité et d’un historique lorsque l’objet est soumis à version ou validation.

L’IT devra produire un dictionnaire de données, un diagramme de relations, les règles de qualité, les règles de dédoublonnage, les mécanismes d’archivage et les procédures de migration depuis l’existant.

12. Administration et paramétrage

Les administrateurs métier devront pouvoir gérer sans intervention de développement les modèles de checklist, questions, critères, pondérations, seuils, catégories d’écarts, statuts, rôles, notifications, fréquences et workflows standards.

Tout paramétrage ayant un impact sur les scores, les contrôles ou les obligations devra être versionné, soumis à validation et associé à une date d’effet. Les changements devront être testables dans un environnement de préproduction avant publication.

13. Migration et reprise de données

Un diagnostic de l’existant devra précéder toute migration. Il devra identifier les données à reprendre, leur qualité, leur propriétaire, leur historique, leur niveau de confidentialité et leur durée de conservation.

La migration devra être réalisée par lots contrôlés avec sauvegarde préalable, rapport d’erreurs, rapprochement des volumes, contrôle d’échantillons et validation métier. Les preuves historiques devront conserver leur contexte, leur date, leur lien avec l’inspection ou le contrôle d’origine et leur statut d’intégrité.

14. Environnements et exploitation

Trois environnements au minimum sont requis : développement, préproduction et production. Les données de production ne devront pas être copiées en développement sans anonymisation ou autorisation explicite.

L’exploitation devra inclure supervision applicative, supervision des synchronisations offline, alertes sur les files de traitement, suivi du stockage probatoire, gestion des certificats, sauvegardes, tests de restauration, gestion des incidents et procédures de reprise.

L’IT devra fournir les éléments suivants : dossier d’architecture, procédures d’installation, guide d’exploitation, guide de supervision, plan de sauvegarde, plan de reprise, matrice des droits, documentation API, dictionnaire de données et dossier de sécurité.

15. Recette et critères d’acceptation

La recette devra être organisée par parcours métier et non uniquement par écran. Chaque exigence identifiée dans le présent document devra être associée à un cas de test, un résultat attendu, une preuve de test et un statut.

Domaine de recette	Critères d’acceptation principaux
Référentiels	Création, versioning, publication, archivage et traçabilité vérifiés.
Contrôles	Planification, exécution, preuves, écarts, validation et escalade fonctionnent.
Audit	Mission, programme, constats, recommandations et clôture indépendante fonctionnent.
Commercial/animation	Objectifs, campagnes, activités, résultats et actions sont correctement consolidés.
Formation	Parcours, compétences, échéances, attestations et recommandations sont gérés.
Qualité	Non-conformités, causes, actions et mesure d’efficacité sont traçables.
Offline	Création et modification hors connexion, reprise, synchronisation et conflits testés.
Sécurité	Accès autorisés et interdits, MFA, séparation des tâches et journalisation testés.
Reporting	KPI, filtres, drill-down, exports et rapports probatoires validés.
Performance	Tests de charge, temps de réponse, reprise et stabilité réalisés.

La recette sera prononcée uniquement si aucune anomalie bloquante ou critique ne subsiste, si les données de test sont rapprochées des résultats attendus, si les procédures d’exploitation sont livrées et si les responsables métiers signent le procès-verbal de validation.

16. Déploiement et conduite du changement

Le déploiement devra commencer par un pilote représentatif comprenant plusieurs agences, zones et profils utilisateurs, ainsi qu’au moins deux domaines fonctionnels. Le pilote devra permettre de mesurer la qualité des référentiels, l’utilisabilité terrain, la robustesse offline, la pertinence des KPI et la charge d’administration.

La conduite du changement devra comprendre une gouvernance projet, des référents métiers, une formation des administrateurs, des supports utilisateurs, des procédures de support, une communication de lancement et un dispositif de collecte des retours.

Étape	Livrable
Cadrage détaillé	Backlog priorisé, architecture cible, modèle de données et critères de succès.
Conception	Maquettes, workflows, règles de score, spécifications API et matrice des droits.
Construction	Lots fonctionnels, tests unitaires, documentation et configuration.
Pilote	Environnement pilote, données contrôlées, formation et rapport d’évaluation.
Généralisation	Plan de déploiement par vagues, support renforcé et suivi des KPI.
Stabilisation	Bilan, corrections, optimisation et décision sur les lots suivants.

17. Critères de succès du projet

Le projet sera considéré comme réussi si les équipes peuvent exécuter les activités prioritaires dans un outil commun, si les responsables disposent d’une vision fiable et explicable, si les actions sont effectivement clôturées avec preuve et si les contrôles critiques sont traçables de bout en bout.

Les indicateurs de succès recommandés sont le taux d’agences actives, le taux de campagnes et contrôles réalisés, la réduction des actions en retard, le délai moyen de clôture, la diminution des écarts récurrents, le taux de synchronisation réussie, le taux de complétion des formations et la satisfaction des utilisateurs.

18. Livrables attendus de l’IT ou de l’intégrateur

Livrable	Contenu attendu
Spécifications détaillées	Règles métier, écrans, workflows, validations et exceptions.
Architecture	Architecture logique, physique, sécurité, flux et dimensionnement.
Modèle de données	Diagrammes, dictionnaire, règles de qualité et stratégie de migration.
Backlog	User stories, priorités, dépendances, estimations et critères d’acceptation.
API	Contrats, documentation, authentification, erreurs et exemples d’appel.
Stratégie de test	Tests unitaires, intégration, sécurité, performance, offline et non-régression.
Dossier d’exploitation	Installation, supervision, sauvegardes, restauration, incidents et astreinte.
Documentation utilisateurs	Guides par rôle, aide contextuelle et procédures métier.
Dossier de recette	Jeux de données, scénarios, résultats et procès-verbal.
Plan de déploiement	Pilote, vagues, formation, support, retour arrière et stabilisation.

19. Questions à trancher en atelier de lancement

Les points suivants devront être décidés avant la conception détaillée : le premier secteur cible, le pays et le cadre réglementaire prioritaire, le nombre d’agences et d’utilisateurs, les systèmes à interfacer, le niveau de profondeur du volet commercial, les responsabilités de validation, les durées de conservation, le mode d’hébergement, les exigences de disponibilité et le périmètre exact du pilote.

Il faudra également valider si le score global doit être commun à tous les clients ou entièrement configurable, si les référentiels réglementaires seront fournis par le client ou maintenus dans BranchCheck, si la formation doit rester légère ou devenir un module complet, et quelles fonctions d’IA sont autorisées dans le premier lot.

20. Référence

[1] BranchCheck — Inspections terrain et conformité des réseaux d’agences, site officiel consulté le 28 août 2026.