Conformité by design : pourquoi elle doit commencer avant l’architecture
Une erreur fréquente consiste à traiter la conformité comme une étape finale :
concevoir d’abord,
tester ensuite,
puis demander aux fonctions juridique, risques, cyber ou conformité de valider le résultat.
Cette séquence paraît efficace.
Elle est souvent coûteuse.
Parce qu’une contrainte identifiée trop tard peut obliger à modifier :
- le modèle de données ;
- les rôles des participants ;
- les permissions ;
- l’architecture ;
- le parcours utilisateur ;
- les contrats ;
- le modèle d’exploitation ;
- parfois même le business case.
La bonne logique est inverse.
La conformité doit participer à la conception dès l’origine.
Pas pour bloquer l’innovation.
Pour éviter de construire une solution que l’organisation ne pourra pas réellement exploiter.
La conformité n’est pas une validation finale
Dans une transformation Blockchain, DLT ou Web3, plusieurs décisions prises très tôt peuvent avoir des conséquences importantes.
Par exemple :
- quelles données seront utilisées ?
- quelles données resteront hors chaîne ?
- qui pourra écrire ?
- qui pourra consulter ?
- qui administrera les identités ?
- comment seront gérées les clés ?
- quels acteurs participeront au dispositif ?
- quelles responsabilités conserveront-ils ?
- que se passe-t-il en cas d’erreur ?
- comment un participant quitte-t-il le système ?
- qui conserve les preuves ?
- comment une décision peut-elle être auditée ?
Ces questions ne sont pas uniquement techniques.
Elles touchent simultanément :
le métier, le juridique, les risques, la cybersécurité, la protection des données et la gouvernance.
C’est précisément pourquoi la conformité ne peut pas être ajoutée une fois l’architecture terminée.
Le premier contrôle commence dès F0
La Méthode F5 ne place pas la conformité uniquement dans F3.
Elle commence dès le cadrage.
En F0, l’objectif n’est pas encore de produire une analyse réglementaire exhaustive.
Il s’agit d’identifier les contraintes capables de modifier immédiatement le mandat.
Le cadrage doit notamment faire apparaître :
- la nature de l’activité envisagée ;
- les catégories d’acteurs ;
- les données critiques ;
- les responsabilités ;
- les principaux risques ;
- les validations nécessaires ;
- les zones d’incertitude.
L’organisation peut ainsi décider suffisamment tôt :
ce qui peut être exploré,
ce qui nécessite une qualification supplémentaire,
et ce qui ne doit pas être engagé tant que certaines conditions ne sont pas levées.
Cette approche permet de transformer une inconnue réglementaire ou de contrôle en condition de décision plutôt qu’en surprise tardive.
F1 : cartographier les faits avant les obligations
Une bonne analyse de conformité ne commence pas par une liste générique de textes.
Elle commence par la réalité opérationnelle.
Il faut comprendre :
- qui fait quoi ;
- quelles données circulent ;
- quels systèmes sont utilisés ;
- quelles organisations interviennent ;
- quels droits sont créés ou transférés ;
- quels contrôles existent déjà ;
- où se produisent les incidents ou exceptions.
Sans cette cartographie, la conformité risque de devenir abstraite.
Une même technologie peut relever de situations très différentes selon le service réellement proposé, les données utilisées, les acteurs concernés et leurs responsabilités.
La logique Maymana consiste donc à partir du besoin, des acteurs, des flux et des risques, et non d’une qualification présumée.
F2 : la conformité peut modifier le business case
Le business case ne doit pas être construit en supposant que toutes les options sont également exploitables.
Une architecture peut sembler intéressante économiquement mais nécessiter :
- des contrôles supplémentaires ;
- une gouvernance plus lourde ;
- des fournisseurs spécialisés ;
- davantage de sécurité ;
- des procédures nouvelles ;
- une documentation renforcée ;
- des compétences spécifiques.
Ces exigences ont un coût.
Elles peuvent donc modifier :
- le TCO ;
- le délai ;
- le modèle opérationnel ;
- la faisabilité ;
- parfois la recommandation elle-même.
La conformité appartient donc au business case.
Elle ne vient pas le valider après coup.
F3 : transformer les exigences en architecture
F3 est le moment où les exigences identifiées deviennent des choix concrets.
Il faut déterminer par exemple :
Données
Quelles informations doivent être présentes dans le registre et lesquelles doivent rester off-chain ?
Identité
Comment les participants sont-ils identifiés et authentifiés ?
Permissions
Qui peut lire, écrire, valider, modifier ou révoquer ?
Clés
Comment sont-elles créées, protégées, renouvelées et récupérées ?
Traçabilité
Quelles décisions doivent pouvoir être reconstituées ?
Intégration
Comment la solution communique-t-elle avec les ERP, CRM, API et référentiels existants ?
Continuité
Que se passe-t-il lorsqu’un composant, un fournisseur ou un participant devient indisponible ?
Le référentiel F5 prévoit explicitement que sécurité, protection des données, risques et conformité soient intégrés à cette conception, et que le pilote ne soit autorisé que lorsque l’architecture est testable, intégrable, réversible et validée par les fonctions compétentes.
Une technologie n’est jamais « conforme par nature »
Une Blockchain permissionnée n’est pas automatiquement conforme.
Un smart contract n’est pas automatiquement sûr.
Une infrastructure privée n’est pas automatiquement mieux gouvernée.
Une trace immuable n’est pas automatiquement une preuve juridiquement suffisante.
La conformité dépend toujours du cas concret.
Il faut examiner :
- le service ;
- les droits ;
- les flux ;
- les données ;
- les rôles ;
- les contrôles ;
- les responsabilités ;
- le secteur ;
- les règles effectivement applicables.
C’est pourquoi les contenus Maymana interdisent les formulations du type :
« conforme par design » comme garantie absolue,
« conformité garantie »,
ou « agrément assuré ».
Le rôle du dispositif est de rendre le projet qualifiable, contrôlable, documenté et gouvernable.
Les données doivent être pensées avant le registre
L’un des sujets les plus sensibles concerne la donnée.
Une architecture distribuée peut encourager une mauvaise intuition :
« Puisque le registre est sécurisé, nous pouvons y mettre l’information. »
La bonne question est différente :
Cette information a-t-elle réellement besoin d’être enregistrée dans le registre ?
Très souvent, la réponse sera non.
Le registre peut ne conserver que :
- un identifiant ;
- un événement ;
- un horodatage ;
- un statut ;
- une empreinte ;
- une preuve permettant de vérifier une donnée conservée ailleurs.
Cette logique réduit l’exposition et facilite :
- la minimisation ;
- la maîtrise des accès ;
- la gestion du cycle de vie des données ;
- la réversibilité ;
- la confidentialité.
La conception on-chain/off-chain est donc à la fois une décision technique et une décision de contrôle.
La conformité doit être testée, pas seulement documentée
Une procédure écrite ne démontre pas qu’un contrôle fonctionne.
C’est pourquoi F4 — le Proof of Business — ne teste pas uniquement la faisabilité et la valeur.
Il doit aussi tester :
- les permissions ;
- les scénarios d’erreur ;
- la gestion des incidents ;
- la sécurité ;
- la continuité ;
- l’auditabilité ;
- les responsabilités ;
- les exceptions ;
- la capacité des équipes à exécuter les contrôles.
Le Proof of Business mesure donc la maîtrise réelle du dispositif.
La Méthode F5 ne recommande le passage à l’échelle que si les seuils de valeur, sécurité, conformité, adoption, intégration et exploitabilité sont atteints.
Un contrôle doit produire une preuve
Une conformité exploitable repose sur une question simple :
pouvons-nous démontrer ce qui s’est passé ?
Pour une décision critique, il doit être possible de reconstituer :
- la donnée d’entrée ;
- la règle appliquée ;
- l’acteur ou le système concerné ;
- la décision ;
- l’exception éventuelle ;
- la correction ;
- la validation.
Autrement dit :
la traçabilité n’a de valeur que si la preuve est complète, lisible, attribuée et exploitable.
Une accumulation de logs ne constitue donc pas automatiquement un dispositif de contrôle.
F5 : la conformité devient un operating model
La conformité by design ne s’arrête pas lorsque le pilote est validé.
À l’industrialisation, l’organisation doit savoir :
- qui contrôle ;
- qui supervise ;
- qui traite les incidents ;
- qui modifie les règles ;
- qui valide les changements ;
- qui forme les nouveaux utilisateurs ;
- comment les tiers sont suivis ;
- comment les contrôles sont revus ;
- comment le dispositif évolue.
La conformité devient alors une capacité opérationnelle permanente.
Le référentiel Maymana est explicite : elle commence en F0/F1, oriente F2/F3, est testée en F4 et devient un operating model en F5.
La conformité protège aussi la valeur
Elle ne doit donc pas être présentée uniquement comme une contrainte.
Une conformité intégrée suffisamment tôt permet notamment :
- d’éviter les reconceptions ;
- de réduire les risques de blocage du pilote ;
- de clarifier les responsabilités ;
- de rendre les décisions auditables ;
- de mieux choisir les fournisseurs ;
- de préparer l’exploitation ;
- de renforcer la confiance des partenaires.
Autrement dit :
la conformité protège le business case en empêchant qu’une valeur théorique repose sur une architecture inexploitable.
Le rôle des fonctions spécialisées reste clair
Maymana ne remplace pas :
- une direction juridique ;
- une fonction conformité ;
- un auditeur habilité ;
- un conseil juridique spécialisé ;
- une autorité.
Le cabinet structure :
- le diagnostic ;
- les faits ;
- les hypothèses ;
- les écarts ;
- les contrôles ;
- les preuves ;
- les responsabilités ;
- les gates.
Lorsque le dossier exige un avis réservé, une certification, une autorisation ou une décision formelle, les fonctions et conseils compétents interviennent.
Cette frontière fait partie de la gouvernance du projet.
La question à poser avant de concevoir
Avant d’autoriser une architecture, un comité peut poser une question simple :
« Quels risques, données, responsabilités et contrôles avons-nous déjà intégrés à la conception — et lesquels restent encore à qualifier ? »
Si la réponse est :
« Nous verrons cela après le pilote »,
le risque est déjà créé.
La bonne séquence est plutôt :
Qualifier → Concevoir → Contrôler → Tester → Exploiter.
C’est le principe de la conformité by design.
La conformité n’arrive pas après la transformation.
Elle fait partie de la transformation.
Vous devez intégrer conformité, risques et contrôle dans une transformation ?
Maymana Consulting accompagne les entreprises et institutions dans la qualification des acteurs, flux, données, responsabilités et contrôles, puis dans leur intégration à l’architecture, au Proof of Business et au modèle d’exploitation.