Problèmes d’application :
vérifier et corriger
Remontez d’un symptôme précis à sa cause. Vérifiez les données, les accès, le réseau, les intégrations et les mises à jour, du signalement au nouveau test.
Identifier la cause.
Vérifier la correction.
Analyse des pannes courantes avec scénarios de test, exemples de critères d’acceptation et méthode de traitement des anomalies.
Partez d’un symptôme reproductible
Le problème peut se situer dans l’interface, le serveur, une intégration ou la définition même du processus. Dire « l’application est lente » ne permet pas de choisir une correction. Il faut connaître l’appareil, la version du système, le numéro de build, l’état du réseau et la suite des actions.
Utilisez les comptes et données de test convenus. Pour chaque anomalie, conservez les résultats attendu et réel, l’heure et un enregistrement d’écran. Ne publiez pas de jetons d’accès, de données personnelles ou de documents de travail dans une discussion commune. Si seul un client rencontre le problème, obtenez d’abord une description des conditions sans informations sensibles.
| Symptôme | Points à vérifier | Critère de validation de la correction |
|---|---|---|
| Un second ticket apparaît après l’envoi. | Requête répétée, réponse perdue et règle de traitement d’une même opération. | Une nouvelle tentative ne crée pas de second enregistrement ; l’utilisateur comprend le statut. |
| Un brouillon disparaît après une mise à jour. | Migration des données locales et compatibilité des versions. | La mise à jour préserve les données convenues et le bon fonctionnement du parcours. |
| Un utilisateur voit l’enregistrement d’une autre personne. | Droits côté serveur et effacement des données locales lors d’un changement de compte. | L’accès reste limité au périmètre autorisé, quel que soit le chemin d’accès. |
| Beaucoup d’installations, peu de résultats. | Le parcours vers une action utile et la fiabilité des événements analytiques. | La cause des abandons est identifiée à partir des actions, et non du nombre de téléchargements. |
Ce tableau oriente l’enquête sans déterminer automatiquement la cause. Un même symptôme peut avoir plusieurs origines. Après correction, reproduisez les conditions initiales, faute de quoi le contrôle restera formel.
Erreur : chiffrer le développement à partir des seuls visuels
La maquette comporte un bouton « Enregistrer », sans définir où vont les données, qui peut les modifier ni ce qui se passe hors connexion. Ces décisions doivent alors être prises pendant le développement. Il en résulte des désaccords sur le périmètre et des modifications constantes d’écrans déjà terminés.
Comment vérifier : choisissez trois parcours principaux et demandez une démonstration de chacun, du début au résultat réel. Précisez les rôles, les champs, les sources de données, les états alternatifs et les critères d’acceptation. Si les participants décrivent des résultats différents pour une même fonction, l’exigence n’est pas encore convenue.
Comment corriger : fixez les limites de la première version et tenez un journal des modifications. Toute nouvelle fonction reçoit une estimation, une priorité et une décision du représentant habilité du client. Ne réduisez pas la gestion des erreurs pour multiplier les écrans : pouvoir réessayer une action sans risque peut compter davantage qu’une rubrique supplémentaire.
Dans l’application d’exemple pour un technicien itinérant, « clôturer le ticket » peut signifier enregistrer le rapport localement, l’envoyer au répartiteur ou recevoir une confirmation d’acceptation. Ce sont trois états différents. La préparation détaillée des exigences figure dans le guide de création d’une application.
Erreur : ne tester que l’écran idéal
Une maquette aux libellés courts paraît soignée, mais une adresse longue masque un bouton dans une fiche réelle. Le clavier cache un champ, le texte agrandi est tronqué et une liste vide ressemble à un blocage. L’utilisateur ne sait plus si l’application fonctionne.
- Remplissez l’écran avec des valeurs longues et vides prévues dans le processus réel.
- Augmentez la taille du texte dans le système et répétez le parcours principal.
- Ouvrez le clavier dans le dernier champ et vérifiez que l’erreur et le bouton restent visibles.
- Revenez en arrière avec la navigation du système et avec les commandes de l’application.
- Vérifiez la lecture des éléments importants par le lecteur d’écran et la clarté des libellés d’action.
La correction doit traiter les retours à la ligne, le défilement, les libellés et les états, au-delà d’une simple réduction de police. Vérifiez aussi la protection contre les suppressions accidentelles et la récupération après une erreur de saisie. Le rouge seul n’explique pas ce qu’il faut changer.
Le résultat attendu : la personne comprend l’état actuel, voit l’étape suivante et corrige sa saisie sans perdre les données déjà remplies. Répétez la vérification sur de petits et grands écrans, avec les réglages d’accessibilité du système.
Erreur : la perte de connexion entraîne une perte de données
Le téléphone passe d’un réseau à l’autre, l’application est mise en arrière-plan et le système peut arrêter son processus. Si l’équipe n’a testé qu’un Wi-Fi stable, les brouillons et envois peuvent se comporter de façon imprévisible. Toute application n’a pas à fonctionner entièrement hors connexion, mais chacune doit expliquer clairement ses limites.
- Commencez à remplir un ticket, puis coupez le réseau.
- Enregistrez par le moyen prévu, puis redémarrez l’application.
- Vérifiez que les champs et pièces jointes convenus sont conservés.
- Rétablissez la connexion et attendez la confirmation de l’échange.
- Répétez le scénario avec une coupure après l’envoi, lorsque le résultat de l’opération est inconnu.
Le rapport est sur le serveur, mais le téléphone propose de le renvoyer
- Constat
- Le serveur a enregistré le rapport, mais la réponse n’est pas parvenue à l’appareil.
- Objectif
- Rattachez les nouvelles tentatives à une même opération et prévoyez la vérification de son statut.
- Vérification
- Reproduisez la perte de réponse dans l’environnement de test. Le système doit contenir un seul rapport et l’application doit afficher son statut confirmé.
La file d’envoi doit être visible. Si un enregistrement entre en conflit avec une modification côté serveur, une ancienne copie ne doit pas écraser silencieusement les données actuelles. Convenez des règles de résolution avec le responsable du processus.
Erreur : limiter les droits en masquant seulement les boutons
Si l’application masque le ticket d’autrui dans la liste, mais que le serveur le renvoie sur demande, le contrôle d’accès n’est pas assuré. Autre risque : les données de l’utilisateur précédent restent sur un appareil partagé après sa déconnexion.
Préparez deux rôles et des enregistrements appartenant à des personnes différentes dans l’environnement de test. Vérifiez la liste, la recherche, les liens directs depuis les notifications et le changement de compte. Demandez à un développeur ou spécialiste de la sécurité de confirmer les contrôles côté serveur sur ces mêmes objets. Ne testez pas de systèmes tiers ou de comptes réels sans autorisation.
Testez séparément le refus d’accès à la caméra, à la localisation ou aux notifications. L’application doit expliquer quelle fonction est indisponible et conserver les autres possibilités lorsque le processus le permet. Demandez les autorisations au moment d’une action compréhensible, au lieu de tout réclamer à la première ouverture.
Pour définir les vérifications techniques, utilisez le référentiel OWASP MASVS. Discutez des exigences applicables au stockage, à l’autorisation, aux échanges et à la confidentialité. Citer formellement une norme dans un rapport ne remplace pas la description des tests réalisés et des limites constatées.
Erreur : confondre écran de réussite et opération réussie
Le bouton a réagi, mais la commande n’est pas arrivée dans le CRM. Une notification est reçue, mais ouvre un autre enregistrement. Le statut du paiement est indéterminé et l’utilisateur réessaie. Ces problèmes se vérifient sur toute la chaîne de systèmes.
| Situation | Éléments à comparer | Critère d’acceptation |
|---|---|---|
| Création d’un ticket. | Identifiant, champs et statut dans l’application, le serveur et le CRM. | Un seul enregistrement avec des données correctes et un responsable identifié. |
| Un service externe est indisponible. | Message, journal des tentatives et mécanisme de relance. | Les données sont préservées ; l’assistance et l’utilisateur voient l’erreur avec le niveau de détail approprié. |
| Une notification est obsolète. | Enregistrement cible, droits actuels et statut à jour. | L’application contrôle l’accès et explique correctement l’indisponibilité. |
| La réponse au paiement est retardée. | Statut chez le prestataire de paiement et dans la commande. | Ni double débit injustifié ni délivrance d’un résultat non payé. |
Testez d’abord les paiements dans l’environnement de test prévu par le prestataire. Convenez séparément des vérifications en production. L’affichage côté client ne doit pas être la seule base de confirmation du paiement.
Chaque échange doit avoir un responsable et permettre de retrouver l’opération par son identifiant. Si seul l’auteur du code peut comprendre la perte d’un ticket, ajoutez les diagnostics nécessaires et une procédure d’assistance. Ces travaux comprennent notamment la configuration du CRM et des intégrations.
Erreur : « Tout fonctionne sur notre téléphone »
Un modèle ne représente pas tout le parc. Les performances dépendent de la mémoire, du volume de données, du réseau et du parcours. Un test avec cinq enregistrements ne valide pas un catalogue de milliers d’objets, et une installation neuve ne couvre pas l’historique d’utilisation.
Convenez d’une matrice d’appareils selon le public : versions des systèmes prises en charge, écrans courants et appareil peu puissant. Testez le démarrage à froid, une longue liste, l’envoi d’une pièce jointe et le retour depuis l’arrière-plan. Notez la durée, les conditions et le résultat ; comparez la même opération après les changements.
Dans le rapport de pré-lancement Google Play, développez l’anomalie et sélectionnez un appareil. Les éléments de diagnostic aident à distinguer un plantage, un blocage et un problème d’interface. Transmettez au développeur le numéro de build et les informations disponibles, puis testez la version corrigée.
Cet outil est utile pour les sites et pages web. La qualité d’une application installée s’évalue avec des outils spécialisés, des parcours sur appareils et l’observation de son fonctionnement réel. Le score d’un site ne prouve pas la rapidité d’un produit mobile.
N’améliorez pas un indicateur en supprimant une fonction : photos masquées, synchronisation désactivée ou écran disparu nécessitent une évaluation de leurs conséquences sur le produit.
Erreur : tester l’installation, mais pas la mise à jour
Une nouvelle version peut fonctionner sur un appareil vierge et perdre des données lors de la mise à jour d’une ancienne installation. Le serveur ne doit pas non plus rendre subitement inutilisables les versions précédentes encore prises en charge : les utilisateurs ne se mettent pas tous à jour en même temps.
- Installez la version précédente encore prise en charge sur un appareil de test.
- Créez les enregistrements, brouillons et états à conserver.
- Mettez l’application à jour par la procédure normale prévue.
- Vérifiez la connexion, les données, les envois, les notifications et le fonctionnement avec le serveur actuel.
- Convenez des mesures en cas de panne : suspendre la diffusion, corriger ou désactiver la fonction concernée si un tel mécanisme existe.
Revenir à une ancienne version du serveur n’est pas toujours compatible avec des données déjà migrées. Testez le plan de reprise à l’avance. Pour iOS, TestFlight permet de distribuer des versions à des groupes et de recueillir les retours des tests.
Analysez un refus de la boutique à partir de la remarque précise. Comparez le comportement réel, la description, les accès de l’évaluateur et les déclarations relatives aux données avec les consignes de l’App Store ou les règles de la plateforme choisie. Corrigez la cause, joignez une explication et testez de nouveau la version. L’approbation ne peut pas être garantie.
Erreur : mesurer les installations plutôt que les tâches accomplies
Une application peut ne jamais planter et rester inutile : l’utilisateur ne trouve pas l’action voulue, ne comprend pas l’inscription ou revient à son canal habituel. Vérifiez d’abord que les événements analytiques représentent le résultat réel.
Exécutez un parcours de test et comparez la chaîne d’événements avec l’enregistrement côté serveur. Vérifiez les clics répétés et les tentatives échouées : ils ne doivent pas augmenter systématiquement le compteur de réussites. Segmentez ensuite les données par version, appareil et utilisateurs nouveaux ou récurrents.
Si le parcours s’interrompt à une étape, observez l’utilisateur et ses conditions d’usage. Changer la couleur d’un bouton ne corrige pas un champ obligatoire dont il ignore la réponse. Supprimez d’abord l’obstacle, puis mesurez l’évolution des actions accomplies et des demandes d’assistance.
N’ajoutez pas de contenu de formulaire superflu aux données analytiques. Le nom de l’événement, la version et le résultat technique suffisent souvent. Il est pertinent de relier le plan d’acquisition à un marketing mesurable après avoir vérifié le parcours menant à une action utile.
Traitez la cause et vérifiez à nouveau le résultat
Rassemblez les anomalies dans un registre unique. Distinguez les défauts confirmés, les nouvelles demandes et les questions sur les exigences. Pour chaque point, indiquez la priorité, le responsable, la version corrigée et le résultat du nouveau test.
| Impact | Exemple | Action |
|---|---|---|
| Critique. | Données d’autrui exposées, enregistrements perdus ou débit incorrect. | Restreindre le parcours concerné selon la méthode convenue, corriger la cause et vérifier les conséquences. |
| Bloque le parcours principal. | Impossible de se connecter ou de finaliser un ticket sur un appareil pris en charge. | Corriger avant la mise en service du parcours concerné. |
| Un contournement fonctionnel existe. | Un élément secondaire est peu pratique, sans perte de données. | Convenir du contournement, du délai de correction et du nouveau test. |
Après correction, vérifiez les fonctions voisines. Une modification de la connexion peut toucher les notifications, et une évolution du stockage local, les brouillons. « Corrigé dans le code » ne remplace pas le test de la version livrée.
Vérifiez aussi la préparation à la maintenance : accès du propriétaire, code source, instructions de compilation, liste des services et responsables. Un autre spécialiste doit pouvoir compiler et lancer le projet à partir de la documentation. Discutez du périmètre de remise en état et d’évolution dans le cadre des travaux sur votre application mobile ; les dépenses après publication sont détaillées dans l’article sur le budget.
À vérifier avant de clore une anomalie
Questions fréquentes sur les problèmes d’application
Pourquoi le problème ne touche-t-il que certains utilisateurs ?
Les appareils, systèmes, réseaux, droits, données et versions de l’application peuvent différer. Commencez par comparer ces conditions. L’absence d’erreur sur le téléphone du développeur ne réfute pas un défaut reproductible dans une autre configuration prise en charge.
Comment distinguer un défaut d’une nouvelle fonction ?
Comparez le comportement au parcours convenu et au critère d’acceptation. Si l’exigence manque ou reste ambiguë, consignez d’abord le résultat attendu. Les nouvelles possibilités sont chiffrées séparément ; les défauts confirmés sont traités selon les conditions du projet.
Faut-il réécrire toute l’application ?
Pas nécessairement. Identifiez d’abord les causes, l’état du code et la possibilité d’une correction ciblée. Comparez les options selon le délai, le risque pour les données et la maintenance future. Une réécriture complète nécessite une analyse technique.
Les tests automatisés suffisent-ils ?
Ils facilitent la répétition de contrôles connus, sans couvrir toutes les conditions ni toutes les attentes métier. Il faut aussi des parcours manuels, des appareils réels et une vérification du résultat dans les systèmes reliés. Le périmètre dépend des fonctions et des risques du produit.
Peut-on publier une application avec des erreurs connues ?
La décision dépend de l’impact et des conditions convenues. Les pertes de données, les accès non autorisés et l’impossibilité d’effectuer l’action principale doivent être corrigés avant la mise en service du parcours concerné. Consignez les anomalies secondaires avec un contournement et un délai de correction.
Que joindre à un signalement au développeur ?
Le numéro de build, le modèle d’appareil, la version du système, les conditions réseau, les étapes, les résultats attendu et réel, l’heure et un enregistrement sans contenu sensible. Ajoutez l’identifiant de l’opération de test s’il existe, sans secrets ni données personnelles superflues.
ANALYSONS LES PROBLÈMES
DE VOTRE APPLICATION
Nous étudierons les parcours, les erreurs reproductibles et l’état du projet, puis définirons les priorités de correction et la vérification des résultats.