Une entreprise confie le développement d’une application mobile à une équipe roumaine. La livraison se passe bien, les tests sont concluants, l’application est mise en production. Six mois plus tard, une bibliothèque tierce utilisée dans le code présente une vulnérabilité critique.
Qui détecte le problème ? Qui décide du correctif ? Qui l’applique ? Ce scénario résume la vraie question posée par un développement d’applications mobiles sur mesure externalisé : la sécurité des données ne s’arrête pas au jour de la livraison.
Roumanie et RGPD : ce que le cadre européen change concrètement
La Roumanie est membre de l’Union européenne. Les flux de données personnelles entre une entreprise française et un prestataire roumain ne constituent pas un transfert vers un pays tiers, ce qui supprime une contrainte contractuelle significative : les clauses contractuelles types ne sont pas nécessaires pour légitimer les échanges de données.
Cette simplification ne dispense pas de poser le rôle du prestataire par écrit. La distinction entre sous-traitant et responsable de traitement doit figurer dans le contrat, avec les mesures de sécurité attendues, la liste des sous-traitants ultérieurs et les droits d’audit. Sans ces clauses, l’avantage du cadre européen commun reste purement théorique.
Le RGPD impose aussi des mesures techniques concrètes que le développement sur mesure permet d’intégrer dès la conception : chiffrement des communications, minimisation des données collectées, gestion fine des permissions sur Android et iOS. Une application mobile sur mesure peut être calibrée exactement sur ce périmètre, là où une solution générique embarque souvent des collectes inutiles.
OWASP Mobile et sécurité by design : ce que le standard évalue vraiment
Le standard OWASP pour les applications mobiles couvre deux dimensions distinctes. La première est technique : chiffrement du stockage local, sécurisation des échanges réseau, gestion des tokens d’authentification. La seconde concerne la protection de la vie privée : minimisation des données, transparence vis-à-vis de l’utilisateur, contrôle laissé à l’utilisateur sur ses propres données.
Cette distinction a des conséquences opérationnelles directes. Une application peut réussir tous les tests de chiffrement et échouer sur la partie vie privée parce qu’elle collecte la géolocalisation en arrière-plan sans en informer clairement l’utilisateur. Dans un développement sur mesure, ces deux angles s’intègrent au cahier des charges initial plutôt qu’en correction après coup.
Le standard OWASP couvre le client mobile. La sécurité du backend doit être évaluée séparément, par des tests spécifiques aux API et aux infrastructures serveur. Un audit limité à l’application installée sur le téléphone laisse une surface d’attaque non examinée.
Cyber Resilience Act et DORA : les obligations qui arrivent
Deux réglementations européennes modifient concrètement les responsabilités autour du développement mobile externalisé.
Le Cyber Resilience Act (CRA) introduit des obligations de cybersécurité pour les produits comportant des éléments numériques, notamment la gestion active des vulnérabilités et la fourniture de mises à jour de sécurité pendant toute la durée de vie du produit.
Le règlement prévoit une entrée en vigueur progressive : les obligations de signalement des vulnérabilités et incidents s’appliquent en premier, suivies des autres dispositions sur une période courant jusqu’en fin 2027. L’application du CRA à une application mobile dépend du produit et du rôle de l’entreprise dans sa mise sur le marché.
DORA s’applique aux entités du secteur financier depuis le 17 janvier 2025. Il leur demande de tenir un registre de leurs contrats de services TIC, d’évaluer les risques liés à chaque prestataire et d’encadrer contractuellement la sous-traitance. Un projet d’application mobile externalisé à une équipe roumaine, s’il soutient une fonction critique, peut déclencher une analyse complète de la chaîne de prestataires.
- Registre des contrats TIC : toute entité financière doit documenter ses prestataires de services numériques, y compris les prestataires de développement mobile, avec l’évaluation des risques associés.
- Clauses de sous-traitance : si le prestataire roumain fait appel à des tiers pour certaines composantes (back-end, infrastructure cloud, tests), ces sous-traitants entrent dans le périmètre d’analyse.
- Droits d’audit : DORA exige que les contrats prévoient explicitement la possibilité pour l’entité financière de vérifier les pratiques de sécurité du prestataire.
Après la livraison : qui surveille les vulnérabilités de votre application mobile ?
Une application mobile livrée n’est pas un produit figé. Les bibliothèques open source qu’elle utilise reçoivent des mises à jour, parfois pour corriger des failles. Les systèmes Android et iOS évoluent et peuvent rendre certains mécanismes de sécurité obsolètes. Les API tierces intégrées peuvent changer leurs conditions ou présenter de nouvelles surfaces d’attaque.
Dans un contrat de développement sur mesure, ce périmètre doit être défini avant la signature. Trois questions structurent cette discussion :
- Surveillance des dépendances : le prestataire s’engage-t-il à monitorer les bibliothèques utilisées et à alerter en cas de vulnérabilité identifiée ? Sur quelle durée, avec quel délai de réponse ?
- Responsabilité en cas de faille post-livraison : si une vulnérabilité est découverte dans du code livré conforme au cahier des charges, qui prend en charge le correctif ? Est-ce inclus dans la garantie ou facturable séparément ?
- Continuité si le prestataire disparaît : le code source est-il déposé en séquestre (escrow), documenté de façon à permettre à une autre équipe de reprendre le projet ? Un prestataire qui ne peut pas répondre à cette question crée un risque de dépendance structurelle.
Ces clauses déterminent la posture de sécurité réelle de l’application à dix-huit mois de la livraison. Les omettre au moment de la négociation expose à des correctifs non couverts par la garantie ou à une dépendance structurelle au prestataire initial.
Choisir un prestataire roumain : les critères techniques qui comptent
Un prestataire roumain opère dans le même cadre réglementaire qu’une entreprise française, ce qui simplifie la contractualisation des flux de données. Cela ne dit rien de sa maturité opérationnelle en matière de sécurité. La capacité à décrire précisément ses pratiques de développement sécurisé, pas à les lister dans une plaquette commerciale, distingue un prestataire solide d’un autre.
Lors de l’évaluation, quelques éléments concrets permettent de tester ce niveau de maturité : le prestataire utilise-t-il des outils d’analyse statique du code (SAST) systématiquement intégrés à son pipeline CI/CD ? Fait-il réaliser des tests de pénétration par une équipe indépendante avant chaque mise en production majeure ? Peut-il présenter un exemple de politique de gestion des vulnérabilités appliquée sur un projet antérieur ?
La Roumanie dispose d’un vivier d’ingénieurs formés dans des environnements exigeants sur la sécurité. Un prestataire peu-disant qui ne documente pas ses pratiques transfère ce coût sur le client, sous forme de correctifs non couverts par la garantie ou de remédiation après incident.
Un cahier des charges qui intègre les exigences OWASP Mobile, les obligations futures du CRA et les droits d’audit DORA dès la consultation permet d’orienter les réponses vers les prestataires qui ont effectivement ces pratiques en place, plutôt que ceux qui savent seulement les décrire.