Appareil perdu ou volé
Par Sebastian · mise à jour le 21 août 2026
Appareil perdu ou volé : Scénario à couvrir par le verrouillage applicatif, l’expiration de session et la révocation des accès à distance.
Cette entrée du glossaire relève de la famille « Sécurité ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.
À quoi sert Appareil perdu ou volé
Sur un projet d’application, Appareil perdu ou volé se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.
Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.
La traduction en exigences
Le cahier des charges doit prévoir qui teste « Appareil perdu ou volé » et à quel moment. Une revue de sécurité programmée après la mise en ligne arrive trop tard pour changer quoi que ce soit.
À écrire noir sur blanc, dans le chapitre qui correspond :
- Le référentiel de sécurité appliqué, nommé dans le contrat.
- Le classement des données manipulées, de la plus banale à la plus sensible.
- La revue de sécurité prévue avant la mise en ligne, et qui la mène.
- La procédure de correction d’une faille signalée, avec son délai d’engagement.
Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.
Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.
Comment le vérifier à la recette
Appareil perdu ou volé se recette avant la mise en ligne, puis se revérifie après les corrections. Un correctif non retesté n’est pas un correctif.
- Demander le rapport d’audit complet, pas la seule page de synthèse.
- Observer le comportement de l’application avec un jeton expiré.
- Vérifier que les contrôles d’accès sont bien refaits côté serveur.
Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.
Les pièges à éviter
Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.
- Traiter la sécurité en fin de projet, quand tout est déjà recetté.
- Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
- Commander un audit sans budgéter les corrections qu’il va produire.
- Laisser les accès de production ouverts à d’anciens intervenants.
- Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.
Termes liés
Les entrées du glossaire déjà publiées sur des sujets voisins :
Questions fréquentes
Qu’est-ce que « Appareil perdu ou volé » ?
Scénario à couvrir par le verrouillage applicatif, l’expiration de session et la révocation des accès à distance. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.
Qui doit s’en charger ?
Le prestataire construit, un tiers vérifie. Faire auditer par celui qui a développé revient à faire corriger une copie par son auteur : utile, insuffisant pour un service exposé au public.
Est-ce que ça se retrouve dans le devis ?
Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.
Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.
Un doute sur ce point de votre projet ?
30 minutes avec un technicien : on relit votre périmètre, on vous dit ce qui manque dans le cahier des charges et à quel palier de prix votre projet se situe. Sans engagement.