Risque lié aux tiers selon DORA : gouvernance des SDK mobiles

Si vous avez suivi cette série, vous disposez désormais de :

• Un périmètre qui définit votre surface de risque mobile (Article 1 : Understanding DORA Compliance for Mobile Teams)
• Des contrôles au niveau de la version qui produisent un verdict clair pour chaque build (Article 2 : DORA Compliance for Mobile Releases)
• Des preuves de résilience liées à de véritables modes de défaillance mobiles (Article 3 : DORA Mobile Resilience Drills)

Il reste un domaine à traiter : le risque lié aux tiers.

Les applications mobiles embarquent des SDK et dépendent de fournisseurs externes à l'exécution. Avec DORA, cette exposition reste de votre responsabilité et doit être gouvernée au niveau de chaque version. Ce point est souvent négligé dans les programmes mobiles, car le « risque fournisseur » est traité comme une formalité administrative plutôt que comme un élément qui se retrouve directement dans le binaire et dans le parcours client.

1) Pourquoi le risque lié aux tiers est différent dans le mobile

Structurellement, une application mobile est un artefact packagé, semblable à une image Docker ou à un WAR Java. Vous regroupez votre code avec des bibliothèques tierces et vous livrez une version précise. Ce point n'a rien de spécifique.

Ce qui est spécifique, c'est ce qui se passe après la livraison. Les équipes backend peuvent généralement corriger et redéployer de façon centralisée sur une infrastructure qu'elles exploitent. Les équipes mobiles livrent via les app stores vers les appareils des clients, et l'adoption d'un correctif dépend du traitement par les stores, des décisions de déploiement, des contraintes des appareils et des mises à jour par les utilisateurs. Les anciennes versions restent donc actives dans la nature, souvent pendant des semaines, voire plus.

Il faut gouverner deux types de risque distincts.

SDK embarqués
Ils sont livrés dans le binaire et s'exécutent avec les privilèges de l'application. Lorsqu'un SDK présente une vulnérabilité, un problème de conformité ou un changement cassant, la remédiation passe par une nouvelle version : vous la corrigez en livrant une nouvelle version de l'application, puis vous attendez son adoption. Concrètement, l'exposition se prolonge sur plusieurs versions de l'application exécutées simultanément.

Fournisseurs à l'exécution
Les services externes comme l'identité, l'OTP, les notifications push, la lutte contre la fraude et les paiements peuvent se dégrader, tomber partiellement en panne ou se comporter différemment selon les environnements. Cette instabilité se manifeste directement dans les parcours mobiles critiques, sur de vrais appareils et de vrais réseaux. Quand elle survient, les clients la voient immédiatement.

L'implication en matière de gouvernance est simple et stricte. Le risque lié aux tiers dans le mobile doit être borné à la version, pertinent à l'exécution et fondé sur des preuves.

2) Modèle de gouvernance des SDK (borné à la version)

L'objectif est de contrôler quel code tiers peut être livré dans chaque version, d'une manière qui puisse être prouvée par la suite. Le modèle commence par l'inventaire, rend ensuite les changements visibles, puis y associe des décisions consignées afin que le verdict de la version soit défendable.

Commencez par un inventaire des SDK par version. Considérez-le comme une base de référence, et non comme un rapport ponctuel : pour chaque version enregistrée, vous devez pouvoir indiquer le nom du SDK, sa version exacte, sa source ou son origine, son rôle fonctionnel et (lorsque vous en disposez) une note de risque ou une classification. Cet inventaire devient le point d'ancrage des approbations, des interdictions, des SLA de correction et de la recherche en cas d'audit.

Exigez ensuite un différentiel par version. Pour chaque nouvelle version, vous devez pouvoir dire quels SDK ont été ajoutés, quelles versions ont changé et ce qui a été retiré, par rapport à la version approuvée précédente. C'est ce qui transforme « nous pensons que rien n'a changé » en « nous pouvons montrer ce qui a changé ».

Une fois que vous voyez les changements, vous pouvez les contrôler. Définissez des règles d'approbation : les nouveaux SDK et les montées de version majeures nécessitent une décision de revue explicite, tandis que les mises à jour de correctifs courantes peuvent suivre un circuit plus léger tant qu'elles restent dans votre politique de versions approuvées. En parallèle, tenez une liste d'interdiction pour les SDK obsolètes, les versions vulnérables ou les fournisseurs non conformes, afin que des risques connus ne puissent pas réintégrer l'application par dérive des dépendances.

Enfin, définissez des SLA de correction alignés sur votre politique de risque et mesurez le délai de correction pour chaque vulnérabilité de SDK. L'essentiel n'est pas la perfection : lorsqu'une correction est retardée, vous devez pouvoir montrer une décision limitée dans le temps plutôt qu'un arriéré incontrôlé.

Champ	Description
Nom du SDK	Nom de la bibliothèque ou du fournisseur
Version	Version exacte incluse dans le build
Source	Fournisseur, dépôt ou origine
Rôle	Analytique, authentification, paiements, etc.
Note de risque	Risque connu, classification ou justification

3) Preuves de type SBOM pour le mobile

DORA n'exige pas un SBOM parfait pour le mobile. Il exige une visibilité sur les dépendances qui soit propre à chaque version, défendable et liée à la gouvernance opérationnelle.

Un SBOM minimal viable pour le mobile est l'inventaire des SDK (nom + version) de cette version, accompagné des références de dépendances que votre outillage de build peut fournir, ainsi que du contexte de vulnérabilités lié à cette version exacte. L'exigence est qu'il soit borné à la version et lié à l'enregistrement de la version, afin de pouvoir répondre à la question « Quelles dépendances étaient présentes dans la version X ? » sans reconstitution à partir du contrôle de version, d'anciens journaux CI ou de connaissances informelles.

4) Contrôles au niveau de la version

Pour rendre la gouvernance des tiers opérationnelle, exprimez-la sous forme de contrôles de version qui produisent des résultats clairs. Il ne s'agit pas de créer davantage de documentation, mais de produire un verdict de version qui reste valide à l'examen.

Un minimum pratique consiste à s'assurer que chaque version dispose d'un inventaire des SDK, d'un différentiel de SDK par rapport à la version précédente, d'une approbation ou d'une exception explicite pour les nouveaux SDK et les montées de version majeures, ainsi que d'une vérification de l'absence de SDK et de versions interdits. Chaque version doit aussi présenter un état des vulnérabilités qui soit soit conforme au SLA, soit couvert par une exception limitée dans le temps. Côté exécution, la version doit renvoyer vers une cartographie des dépendances aux fournisseurs pour les parcours critiques et référencer les décisions de dégradation et de repli définies pour ces parcours.

Si vous disposez déjà d'un pipeline de verdict décrit dans l'Article 2 : DORA Compliance for Mobile Releases, ces éléments deviennent les entrées « tiers » de ce même verdict. L'enregistrement de la version reste l'endroit unique où se trouvent la décision et les liens vers les preuves.

5) Dossiers de preuves prêts pour l'audit (par version)

À ce stade, les preuves convergent au niveau de la version. Un dossier de preuves n'est pas « tout ce que vous avez » : c'est l'ensemble minimal d'artefacts qui expliquent pourquoi la version était acceptable lors de son déploiement.

Un dossier de preuves de version doit inclure :

• L'identité de la version (ID de l'application, version, référence de build, empreinte de l'artefact)
• L'inventaire et le différentiel des SDK
• Les approbations et exceptions
• La cartographie des fournisseurs par parcours critique
• Les définitions de dégradation et de repli
• Les résultats des contrôles de l'Article 2 : DORA Compliance for Mobile Releases
• Les preuves de résilience de l'Article 3 : DORA Mobile Resilience Drills

Ce qui distingue « nous avons des preuves » de « nous sommes prêts pour l'audit », c'est la capacité à les retrouver : maintenez donc un index simple, organisé par version, qui renvoie au contenu du dossier.

Pour éviter que les exceptions ne deviennent des lacunes, standardisez un enregistrement d'exception. Il doit indiquer le périmètre (SDK ou fournisseur), la ou les versions concernées, la justification, le responsable du risque, les contrôles compensatoires, une date d'expiration ou de revue, ainsi que l'horodatage de l'approbation. Cela transforme « nous n'avons pas pu corriger » en « nous avons pris une décision limitée dans le temps, avec un responsable et des contrôles ».

La conservation devient alors simple : gardez l'enregistrement de la version, le dossier de preuves et l'index conformément à vos politiques internes et réglementaires. L'essentiel est que les preuves restent bornées à la version, indexées et récupérables à la demande.

6) Reporting à la direction (focus sur les tendances)

Au niveau de la direction, l'objectif est la visibilité des tendances plutôt que de rediscuter chaque version. Trois indicateurs fonctionnent généralement bien. L'ancienneté des exceptions montre si les décisions de risque sont réexaminées ou deviennent permanentes. Le délai de correction des vulnérabilités de SDK montre si votre chaîne d'approvisionnement mobile est réactive. Le taux de changement des SDK par version mesure le renouvellement des dépendances, qui est fortement corrélé à la charge de revue et aux risques imprévus.

Commencer petit, puis étendre

Mettez en œuvre la démarche progressivement, sans casser le train de releases. Commencez par l'inventaire des SDK et les différentiels par version, car la visibilité donne un levier. Ajoutez ensuite les approbations pour les nouveaux SDK et les montées de version majeures, puis l'application de la liste d'interdiction et le suivi des SLA de correction avec des exceptions limitées dans le temps.

Une fois la gouvernance des SDK stabilisée, cartographiez les dépendances aux fournisseurs pour chaque parcours critique et documentez les décisions de repli. Enfin, formalisez un index des dossiers de preuves et leur conservation, afin que la recherche devienne une routine plutôt qu'un projet exceptionnel.