Conformité DORA pour les versions mobiles : le socle minimal, le verdict et le modèle d'exceptions les plus simples

Si vous avez lu le premier article de cette série, DORA Compliance for Mobile Teams: Understanding scope and what you need to do, vous avez déjà les bases.

1/ Vous connaissez votre périmètre mobile et vous comprenez pourquoi la version (release) est l'unité naturelle de gouvernance,

2/ Vous avez la question qui garde la conformité DORA pragmatique : cette version de l'application mobile est-elle conforme à nos contrôles de sécurité applicative et de résilience alignés sur DORA ?

Il s'agit maintenant de rendre cette question répondable de façon reproductible et auditable.

Cet article traite de la mécanique de la conformité DORA pour les versions mobiles. Nous allons définir un socle minimal de contrôles pour le mobile, présenter un modèle de verdict simple et voir comment gérer les exceptions sans transformer chaque version en négociation de gouvernance.

Commençons par expliquer pourquoi ce travail est centré sur la version, et non sur une conformité générique.

Pourquoi la version est l'unité la plus pratique de la conformité DORA pour le mobile

La conformité mobile devient difficile quand on cherche à affirmer globalement « notre application est conforme à DORA ». Cette affirmation mélange gouvernance organisationnelle, supervision des tiers, processus d'incident et contrôles techniques dans une seule déclaration qu'il est presque impossible de documenter proprement du point de vue d'une équipe mobile.

La version est une meilleure unité, car c'est déjà ainsi que le travail mobile s'organise. Chaque version iOS et Android représente un changement distinct. Le risque change avec elle. Les preuves peuvent être collectées au moment de la version, plutôt que reconstituées plus tard lorsque quelqu'un envoie une demande d'audit.

Quand vous traitez la version comme l'unité de la conformité DORA, trois choses se produisent :

• Les preuves sont collectées naturellement, dans le cadre de la livraison.
• Les décisions de risque sont prises explicitement, et non présumées.
• Le récit de conformité est cohérent, version après version.

Nous allons maintenant définir un socle suffisamment petit pour être maintenu et suffisamment solide pour être utile.

Le socle de conformité DORA pour les versions mobiles

La façon la plus simple de rendre la conformité DORA concrète pour une équipe mobile est de définir un socle. Un socle est simplement une liste de contrôles que chaque version doit respecter avant d'être livrée. Limitez-le à 10 à 20 contrôles au maximum. Au-delà, il devient une charge de maintenance plutôt qu'un outil de gouvernance.

Un bon contrôle a trois propriétés. Il est binaire ou presque, c'est-à-dire que l'on peut dire s'il est réussi ou échoué. Il est lié à une preuve, c'est-à-dire que l'on peut désigner un artefact, un rapport ou un ticket. Et il a un responsable, c'est-à-dire que quelqu'un en répond en cas d'échec.

Un rappel avant d'aller plus loin. Cette partie peut devenir compliquée si vous le laissez faire. Restez simple. Si le contrôle ne peut pas être prouvé, ce n'est pas encore un contrôle.

Voici cinq catégories qui couvrent l'essentiel de la conformité DORA dans un périmètre mobile.

1) Intégrité et traçabilité des versions

Cette catégorie répond à la question : savez-vous exactement ce qui a été livré, et pouvez-vous le prouver plus tard ? Concrètement, cela signifie que chaque artefact de version est identifié de façon unique par une version, un numéro de build et une empreinte, et qu'il est signé et produit par un pipeline approuvé. Cela signifie aussi que vos contrôles de sécurité s'exécutent sur l'artefact exact de la version candidate, et non sur un build de développeur ou une approximation de l'environnement de préproduction, et que vous disposez d'un enregistrement de provenance qui relie l'artefact à un commit, à un dépôt et à une exécution de pipeline. Enfin, les preuves associées sont conservées afin de pouvoir être examinées plus tard sans dépendre de la mémoire de qui que ce soit.

C'est la catégorie ennuyeuse mais essentielle : si vous ne pouvez pas identifier l'artefact, plus rien d'autre n'est attribuable.

2) Seuils de vulnérabilités et d'exposition

Cette catégorie répond à la question : cette version respecte-t-elle notre tolérance au risque définie ?

Des contrôles qui évitent les ennuis aux équipes :

• Aucune vulnérabilité critique dans la version.
• Aucune vulnérabilité élevée dans les catégories critiques pour le mobile, typiquement l'authentification et la gestion de session, la cryptographie, le stockage de données sensibles, la sécurité du transport et la configuration non sécurisée.
• Aucune nouvelle régression critique ou élevée par rapport à la dernière version approuvée.
• Des attentes de remédiation existent pour les vulnérabilités non bloquantes afin que le risque ne s'accumule pas silencieusement.

L'essentiel est de définir les seuils avant de les appliquer. « Nous le reconnaîtrons en le voyant » n'est pas un contrôle.

3) Gouvernance des SDK tiers

Cette catégorie répond à la question : savons-nous ce que contient le binaire, et maîtrisons-nous la façon dont il évolue ?

Des contrôles qui rendent le risque lié aux SDK gérable :

• Un inventaire des SDK existe pour cette version et liste chaque SDK et bibliothèque intégrés.
• Un différentiel existe et montre ce qui a changé depuis la dernière version approuvée.
• Les nouveaux SDK ou les mises à niveau de version majeure exigent une approbation explicite et un responsable désigné.
• Les classes de SDK interdites ou les versions de SDK connues comme vulnérables sont bloquées avant livraison.
• Un processus existe pour réagir rapidement aux avis de sécurité critiques sur les SDK, avec une attente de correctif définie.

Le mobile a un profil de risque tiers particulier, car les dépendances sont livrées à l'intérieur de l'application. Un SDK peut collecter des données inattendues, casser un parcours ou introduire une vulnérabilité sans aucun changement dans votre propre code. C'est dans cette catégorie que la conformité DORA devient très spécifique au mobile.

4) Préparation à la résilience pour les parcours critiques

Cette catégorie répond à la question : avons-nous testé les modes de défaillance qui comptent le plus pour les clients ?

Des contrôles qui évitent que la « résilience » reste vague :

• Les parcours critiques sont déclarés pour l'application, comme la connexion, l'authentification renforcée, la récupération de compte et les paiements.
• Des cartes de dépendances existent pour chaque parcours et couvrent l'identité, l'OTP et les notifications push, les API, la fraude, les paiements et la configuration distante.
• Des plans de retour arrière, des kill switches et des garde-fous de feature flags existent pour les fonctionnalités à haut risque et ont été testés.
• Les preuves d'exercices de résilience sont jointes et liées dans le dossier de version.

C'est la catégorie qui sépare « nous sommes sécurisés » de « nous sommes résilients ». La sécurité et la résilience sont liées, mais ce n'est pas la même chose.

5) Préparation aux incidents

Cette catégorie répond à la question : si quelque chose tourne mal avec cette version, pouvez-vous réagir rapidement et proprement ? Concrètement, cela signifie que votre télémétrie permet une analyse par version, afin d'identifier quelles versions de l'application sont touchées et comment l'impact évolue à mesure que les mesures d'atténuation sont appliquées. Cela signifie aussi que vous avez des critères clairs de gravité des incidents pour les événements de sécurité mobile, y compris les signaux de fraude et de prise de contrôle de compte, ainsi qu'un modèle de dossier de preuves qui peut être rempli rapidement sans investigation numérique manuelle. Enfin, il vous faut un processus de journal de décisions qui enregistre ce qui a été décidé, par qui et sur quelle base, afin que le récit de l'incident soit cohérent et vérifiable. La préparation aux incidents est souvent la dernière catégorie que les équipes construisent, mais c'est celle qui compte le plus quand quelque chose tourne réellement mal.

Une fois le socle en place, il faut aussi une manière cohérente d'exprimer le résultat de chaque revue de version.

Le modèle de verdict de version pour la conformité DORA

Une fois le socle en place, chaque version candidate doit produire l'un de ces trois résultats.

PASS

Tous les contrôles sont respectés. Les preuves sont complètes et liées au dossier de version. La version peut être livrée.

FAIL

Un ou plusieurs contrôles bloquants ne sont pas respectés. La version n'est pas livrée tant que les blocages ne sont pas levés ou traités formellement par une exception.

PASS_WITH_EXCEPTIONS

La version respecte le socle uniquement parce qu'un ou plusieurs contrôles sont levés par une exception formellement approuvée. C'est un résultat encadré, pas un raccourci.

Un modèle à trois états est plus honnête qu'un modèle binaire. Dans le BFSI mobile, il faut parfois livrer pour traiter un risque plus prioritaire, et une exception formelle assortie de contrôles compensatoires est plus responsable que de faire comme si tout allait bien.

Les exceptions sont l'endroit où les programmes restent soit disciplinés, soit dérivent lentement vers le « nous corrigerons plus tard ».

Comment gérer les exceptions sans tout ralentir

Les exceptions ont mauvaise réputation parce qu'elles sont souvent informelles et permanentes. Une exception bien gouvernée est en réalité un outil utile. Elle vous permet de faire explicitement un arbitrage contrôlé, plutôt que de laisser le risque s'accumuler discrètement.

Une bonne exception a besoin de cinq éléments :

• Un ID pour pouvoir la suivre d'une revue à l'autre.
• Un responsable chargé de la résoudre.
• Un énoncé du risque en langage clair qui explique quel est le risque et pourquoi il est acceptable pour le moment.
• Des contrôles compensatoires qui réduisent l'impact pratique tant que l'exception est active.
• Une date d'expiration qui force un suivi. Si elle n'expire pas, ce n'est pas une exception. C'est un changement de politique.

La règle de gouvernance est simple. PASS_WITH_EXCEPTIONS n'est valide que lorsque les cinq éléments sont présents et approuvés par les bonnes personnes, typiquement la Sécurité et le Risque ensemble.

Suivez les exceptions comme une métrique. Si le nombre d'exceptions augmente et que le respect des dates d'expiration est faible, votre socle n'est pas appliqué. Il est contourné.

Nous allons maintenant relier cela au dossier de version, car c'est ce qui rend les audits et les revues beaucoup moins pénibles.

Les champs minimaux du dossier de version (pour faciliter les audits)

Le dossier de version relie le verdict aux preuves et rend l'ensemble du modèle auditable. Voici les champs minimaux que chaque dossier de version doit contenir.

Identité de la version

• Identifiant de l'application (bundle id ou nom de paquet)
• Plateforme (iOS ou Android)
• Version et numéro de build
• Empreinte de l'artefact ou ID de build unique
• Référence source (dépôt, SHA du commit, ID d'exécution du pipeline)
• Responsable de la version

Verdict

• PASS, FAIL ou PASS_WITH_EXCEPTIONS
• Synthèse des contrôles : lesquels ont réussi, lesquels ont échoué
• Liste des blocages si FAIL : ID de la vulnérabilité ou du problème, responsable et objectif de remédiation
• Liste des exceptions si PASS_WITH_EXCEPTIONS : ID de l'exception, contrôle levé, expiration, approbateur

Liens vers les preuves

• Rapport de test de sécurité lié à l'artefact
• Export des vulnérabilités avec leurs sévérités et catégories
• Inventaire et différentiel des SDK
• Preuves d'exercices et liens vers les runbooks pour les parcours critiques
• Piste d'approbation et entrées du registre des exceptions

Si vous avez ces champs, un auditeur peut examiner plus tard une décision de version sans demander à l'équipe de tout reconstituer de zéro. C'est là que réside la valeur pratique.

Dernier élément : le déploiement. L'objectif est que cela ressemble à une livraison normale, et non à une nouvelle cérémonie.

Comment le déployer sans casser le train de releases

L'erreur la plus fréquente des équipes est d'essayer de tout imposer d'un coup. Cela crée des blocages, ralentit les versions et fait paraître le socle comme un obstacle plutôt que comme un outil.

Une meilleure approche consiste à commencer étroit puis à élargir.

Commencer par un seul point de blocage strict

Choisissez le contrôle le plus important et imposez-le comme bloquant. Un bon premier choix est « aucune vulnérabilité critique ». Tout le reste peut être mesuré, mais sans être bloquant pendant les premières versions.

Ajouter les contrôles progressivement

À mesure que les équipes se familiarisent avec le modèle, ajoutez les contrôles un ou deux à la fois. L'objectif est que le socle ressemble à une partie normale de la livraison, et non à un exercice de conformité à part.

Automatiser tôt la collecte des preuves

Plus tôt vous automatisez la production des preuves, moins le modèle est pénible. Commencez par des rapports de scan liés aux artefacts, puis ajoutez les différentiels de SDK, puis les vérifications d'exercices et de runbooks.

Rendre les exceptions visibles dès le premier jour

Même si vous utilisez rarement les exceptions au début, rendez-les traçables et limitées dans le temps dès le départ. Il est beaucoup plus difficile d'ajouter de la gouvernance aux exceptions après des mois d'informalité.

Conclusion

Un socle de contrôles n'a pas besoin d'être parfait pour être utile. Il doit être cohérent, appuyé sur des preuves et appliqué. Quand chaque version iOS, Android ou HarmonyOS produit un verdict et un dossier de preuves lié, la conformité DORA cesse d'être une course trimestrielle. Elle devient une production naturelle de la façon dont le mobile est livré.

Dans le prochain article, nous passerons des contrôles de version à la résilience opérationnelle. Nous présenterons la bibliothèque d'exercices la plus simple pour les parcours mobiles BFSI, les preuves que chaque exercice doit produire, et la manière de boucler la boucle entre les résultats des exercices et les contrôles de version.

À suivre : Mobile Operational Resilience Under DORA: The simplest drill library for BFSI journeys