Audit d’application mobile : grille UX, technique et sécurité
Un audit d’application mobile sert à décider quoi corriger, conserver ou reconstruire à partir de faits observables. Avant de lancer une refonte, examinez les parcours utilisateurs, la fiabilité technique, les accès aux données et les conditions de maintenance. Le livrable utile est une liste de constats vérifiables, avec une priorité, un responsable et un test de correction.
Une collection de captures annotées ne suffit pas si personne ne peut reproduire les problèmes. À l’inverse, une analyse du code ne répond pas à elle seule à la question métier : les utilisateurs peuvent-ils accomplir leur tâche ? Cette grille vous aide à réunir ces deux perspectives sans confondre audit produit, test de sécurité et avis juridique.
Choisissez la décision que l’audit doit éclairer
Commencez par une question précise : faut-il corriger l’existant, reprendre un parcours ou remplacer une dépendance devenue difficile à maintenir ? Notez le symptôme, les personnes concernées et les informations qui vous manquent. Évitez de partir du principe qu’une refonte complète est déjà nécessaire.
Par exemple, des utilisateurs peuvent abandonner une saisie parce qu’ils ne comprennent pas le bouton final, parce que l’enregistrement échoue ou parce qu’ils ne retrouvent pas le résultat. Ces situations produisent parfois le même signal apparent. Elles nécessitent pourtant des vérifications et des corrections différentes.
Définissez également le périmètre : version de l’application, plateformes, appareils, comptes de test, environnement serveur et parcours étudiés. Un constat doit rester rattaché à ce périmètre. Il ne prouve pas que toutes les versions ou tous les utilisateurs rencontrent le même problème.
Copiez cette grille d’audit
| Axe | Question à vérifier | Preuve à conserver | Décision possible |
|---|---|---|---|
| Parcours principal | La personne termine-t-elle sa tâche et comprend-elle le résultat ? | Scénario, enregistrement et état final | Clarifier une étape ou corriger un blocage |
| Fiabilité | Que se passe-t-il après une coupure réseau ou une interruption ? | Étapes reproductibles, logs utiles et version | Corriger la reprise ou la persistance |
| Accès | Chaque rôle accède-t-il uniquement aux fonctions prévues ? | Comptes de test et contrôle côté serveur | Revoir les autorisations |
| Données | Les traitements observés correspondent-ils aux explications fournies ? | Inventaire, finalités et parcours de permission | Clarifier, limiter ou examiner le traitement |
| Accessibilité | Le parcours reste-t-il utilisable avec les réglages et aides ciblés ? | Appareil, réglages, lecteur d’écran et obstacles | Corriger les libellés, le focus ou la présentation |
| Maintenance | Une autre personne peut-elle construire et exploiter le produit ? | Accès autorisés, procédure et essai de build | Compléter la passation ou isoler une dépendance |
Conservez une ligne par problème. N’écrivez pas « UX à refaire » : décrivez le déclencheur, ce que la personne observe et ce qui devrait se produire. La précision permet de vérifier ensuite que la correction traite bien le problème initial.
Préparez des accès limités et un contexte reproductible
Utilisez des comptes de test adaptés aux rôles étudiés. Préférez des données fictives ou préparées pour l’exercice lorsque cela permet de reproduire le comportement. Ne transmettez pas des identifiants de production dans un document partagé. Définissez qui reçoit les accès, pour quelle durée et comment vous les révoquerez.
Réunissez le code et la documentation disponibles, les versions distribuées, les parcours prioritaires et les incidents déjà connus. Une absence de documentation est elle-même un constat de maintenance ; elle ne justifie pas d’inventer le fonctionnement du produit. Si vous ne pouvez pas vérifier un comportement serveur, marquez ce point comme non vérifié.
Pour préparer les éléments à remettre au prestataire, utilisez l’audit de passation d’application. Il complète la revue fonctionnelle avec les questions de comptes, de sources et d’exploitation.
Examinez un parcours complet avant de compter les écrans
Choisissez une tâche fréquente et suivez-la de son déclencheur à son résultat. Testez le cas normal, un refus de permission, une saisie incomplète et une interruption pertinente. Notez les messages, les possibilités de retour et la manière dont l’utilisateur retrouve son travail.
Vous pouvez ensuite comparer les observations avec les tests à effectuer avant une livraison mobile. Le présent audit sert à diagnostiquer un produit existant et à décider d’une intervention. La checklist de recette sert à vérifier une version avant de l’accepter. Les deux documents n’ont pas le même rôle.
Un exemple fictif de constat exploitable
Imaginez une application de suivi d’interventions appelée AtelierNord. Un technicien commence un rapport, perd le réseau puis ferme l’application. À la réouverture, le rapport n’apparaît plus. Cet exemple est fictif et ne décrit aucune mission client.
| Champ | Exemple de contenu |
|---|---|
| Déclencheur | Créer un rapport de test, couper le réseau, fermer puis rouvrir l’application |
| Observation | Le rapport n’apparaît pas dans la liste locale |
| Incertitude | La disparition visuelle ne prouve pas encore la suppression des données stockées |
| Vérification suivante | Examiner la persistance locale avec l’équipe technique et reproduire le scénario |
| Critère de correction | Le technicien retrouve le brouillon et son état de synchronisation après réouverture |
| Preuve de validation | Enregistrement du même scénario sur la version corrigée et contrôle technique associé |
Cette formulation distingue le symptôme, l’hypothèse et la preuve. Elle évite de commander immédiatement une nouvelle application alors qu’une correction ciblée peut suffire. Elle évite aussi de déclarer le problème résolu après un simple changement de texte.
Séparez sécurité, protection des données et qualité d’usage
Le référentiel OWASP MASVS structure les exigences de sécurité des applications mobiles. Il fournit un cadre de contrôle, pas un certificat automatique de sécurité. Pour une évaluation spécialisée, définissez les contrôles concernés et les preuves attendues avec une personne qualifiée.
En France, les recommandations de la CNIL sur les applications mobiles aident à examiner les responsabilités et la protection des données. Une permission technique du téléphone ne règle pas à elle seule la question du fondement juridique. Faites examiner les traitements et les obligations applicables par les responsables compétents.
Pour l’usage, contrôlez les libellés, le contraste, l’ordre de navigation et les aides réellement prises en charge. Les WCAG du W3C offrent des références d’accessibilité pour le contenu web. Ne présentez pas une vérification partielle comme une conformité complète de l’application native.
Priorisez les corrections par conséquence observable
Traitez d’abord les blocages du parcours essentiel, les pertes de travail confirmées et les problèmes d’accès qui nécessitent une intervention. Documentez ensuite les difficultés répétées et les améliorations de compréhension. La taille apparente d’un écran ne détermine pas l’importance du problème.
Pour chaque correction, nommez un responsable et le scénario qui devra réussir. Si une dépendance empêche d’agir, décrivez-la. Lorsque plusieurs corrections touchent la même partie du produit, comparez une reprise ciblée avec une refonte plus large à partir des contraintes réelles, sans annoncer un gain chiffré que vous n’avez pas mesuré.
Transformez les constats en périmètre de travail
Une fois les preuves réunies, regroupez les corrections par parcours et distinguez ce qui est nécessaire de ce qui peut attendre. Utilisez le cahier des charges d’application mobile pour traduire les décisions en critères d’acceptation.
Apportez à Doved Studio un parcours prioritaire, un constat reproductible et les contraintes de l’existant. Nous réunissons cadrage produit, conception et développement pour préciser l’intervention utile. Commencez par préparer cette fiche de constat ; elle donne une base concrète à la discussion et évite une demande générale de « modernisation ».
Questions fréquentes
Un audit oblige-t-il à refaire toute l’application ?
Non. Il doit permettre de comparer les options. Une correction, une reprise de parcours ou une amélioration de la maintenance peut répondre au problème sans refonte complète.
Peut-on commencer sans accès au code ?
Vous pouvez examiner les parcours visibles et préparer des constats reproductibles. Les conclusions sur l’architecture, les accès serveur ou la persistance resteront limitées tant que vous ne disposez pas des preuves nécessaires.
Quel livrable demander ?
Demandez le périmètre, les observations, les preuves, les incertitudes, les priorités et les tests de correction. Une liste de recommandations sans lien avec des constats vous aidera moins à décider.
Quand faut-il refaire les contrôles ?
Rejouez les scénarios après les corrections et après une modification importante du parcours ou de ses dépendances. Conservez la version testée pour ne pas attribuer une ancienne validation à une nouvelle livraison.
