RGPD et application mobile : la conformité en pratique
5 min de lecture
À retenir
- Si une seule personne sait publier l’application, vous avez un risque d’entreprise, pas un détail technique.
- Automatisez d’abord la compilation, ensuite les tests, enfin la publication.
- La distribution aux testeurs internes est le gain le plus immédiat de toute la chaîne.
- Chaque version doit être traçable jusqu’à la ligne de code qui l’a produite.
- Une chaîne complète représente cinq à dix jours et se rentabilise en un trimestre.
Dans beaucoup d’équipes, publier une version mobile ressemble encore à ceci : une personne, sur sa machine, trois heures de manipulations, deux certificats qu’il faut retrouver, un numéro de version incrémenté à la main, et une prière avant d’envoyer.
Ce n’est pas un problème de confort. C’est un risque d’entreprise : cette personne peut être en congé, malade, ou partie.
Les quatre niveaux d’automatisation
Chacun apporte un bénéfice propre ; on peut s’arrêter à n’importe quel niveau.
Niveau 1 — La compilation reproductible (1 à 2 jours)
Une commande produit un binaire signé, depuis n’importe quelle machine, sans configuration manuelle. Les certificats et clés sont stockés de façon chiffrée et récupérés automatiquement.
Ce que ça élimine : le « ça compile chez moi », la dépendance à une machine, et la panique quand un certificat expire — un incident classique décrit dans notre article sur la maintenance.
Niveau 2 — Les vérifications automatiques (1 à 2 jours)
À chaque proposition de modification : compilation, analyse statique, tests unitaires, contrôle de style. Rien ne peut être intégré si la compilation échoue.
Ce que ça élimine : les régressions les plus bêtes, et les discussions de style en revue de code — la machine les tranche, les humains parlent d’architecture.
Niveau 3 — La distribution automatique aux testeurs (1 jour)
Chaque intégration produit une version installable, distribuée automatiquement à l’équipe et aux testeurs métier, avec les notes de version générées à partir des modifications.
C’est le gain le plus immédiat de toute la chaîne. Le retour métier passe de « à la prochaine livraison » à « demain matin », et les malentendus se règlent avant d’être coûteux.
Niveau 4 — La publication automatisée (1 à 3 jours)
Envoi de la version aux magasins, mise à jour des métadonnées et des captures, numérotation automatique, étiquetage du dépôt.
La validation par la plateforme reste une étape externe, et il est sain de garder un déclenchement manuel pour la mise à disposition finale — mais tout ce qui précède se fait sans intervention.
Le test qui révèle la maturité d’une équipe : demandez à quelqu’un qui n’a jamais publié l’application de le faire, seul, avec la documentation existante. Le temps qu’il met — et le nombre de fois où il doit demander de l’aide — mesure exactement votre dépendance à une personne.
Ce qu’il faut tester, et ce qu’il ne faut pas
L’erreur classique est de viser une couverture exhaustive. Sur mobile, c’est coûteux et peu rentable : l’interface change souvent, et des tests trop fins cassent à chaque modification de design.
Ce qui vaut le coup :
- la logique métier pure — calculs, règles, transformations : rapide à tester, stable dans le temps ;
- les trois à cinq parcours critiques de bout en bout — connexion, parcours principal, paiement ;
- la sérialisation des données échangées avec le serveur, cause fréquente de plantages silencieux ;
- un test de non-régression visuelle sur les écrans les plus sensibles, si le produit le justifie.
Ce qui ne vaut pas le coup : tester chaque écran, chaque animation, chaque état visuel. Le coût de maintenance de ces tests dépasse rapidement leur valeur.
La traçabilité, souvent oubliée
Chaque version installée par un utilisateur doit pouvoir être reliée à la ligne de code qui l’a produite. Concrètement : le numéro de version affiche l’identifiant de la modification, le dépôt est étiqueté à chaque publication, et l’outil de suivi des plantages reçoit les fichiers de symboles correspondants.
Sans cela, un rapport de plantage sur une version publiée trois mois plus tôt est indéchiffrable, et vous corrigez à l’aveugle.
5–10 jMise en place d’une chaîne complète sur les deux plateformes
1 trim.Délai courant de rentabilisation
3–5Parcours critiques suffisent en tests de bout en bout
Le calcul de rentabilité
Une équipe qui publie deux fois par mois, avec trois heures de manipulation par publication et une heure de correction des problèmes de dernière minute, consomme environ 96 heures par an en publication manuelle.
Une chaîne complète représente sept jours de mise en place, soit environ 56 heures. Elle est rentabilisée en sept mois sur le seul temps passé — sans compter la suppression du risque de dépendance, ni les régressions évitées, ni la vitesse de retour métier.
Sur une équipe qui publie chaque semaine, la rentabilisation intervient en moins d’un trimestre.
Automatiser la livraison ne rend pas l’équipe plus rapide sur le moment. Cela rend la livraison ennuyeuse — et une livraison ennuyeuse est une livraison qu’on ose faire souvent.
Par où commencer demain
Niveau 1, rien d’autre. Une commande qui produit un binaire signé, depuis n’importe quelle machine. Deux jours, et vous avez supprimé le risque le plus grave.
Le reste peut attendre le trimestre suivant : chaque niveau apporte sa valeur indépendamment, et rien n’oblige à tout construire d’un coup.
