Que peut contenir le rapport de plantage d'une application de journal intime ?
Le rapport de plantage d'une application de journal intime peut inclure des détails techniques tels que la trace de la pile (stack trace), les versions de l'appareil et de l'application, des horodatages et des événements de diagnostic récents. Selon le système d'exploitation, le service de rapport et la configuration de l'application, il peut également contenir des journaux, des pièces jointes ou des données de relecture de session exposant le contenu saisi ou affiché dans l'application. Un rapport ne contient pas systématiquement des entrées de journal dans tous les cas, et il n'est pas prudent de supposer qu'il n'en contient jamais. Vérifiez le rapport spécifique et la manière dont l'application est configurée avant de le partager.
Que montre un rapport de plantage standard ?
Une trace de la pile (stack trace) répertorie les appels de fonctions associés au plantage. Elle aide les développeurs à localiser le chemin de code concerné, mais n'explique généralement pas, à elle seule, l'ensemble des circonstances et ne prouve pas ce que faisait l'utilisateur. Les rapports peuvent également identifier les versions de l'application et du système d'exploitation, le modèle de l'appareil, l'heure du plantage et d'autres détails d'environnement. Apple décrit les rapports de plantage comme des enregistrements de l'état de l'application au moment d'un incident et recommande d'analyser le rapport complet du système d'exploitation ; son guide identifie des champs tels que les informations sur l'appareil, l'application et l'OS. Consultez le [guide d'analyse des rapports de plantage](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report) d'Apple.
Le format du rapport dépend de sa source. Les rapports de plantage Apple collectés via Xcode et un rapport de bug Android sont des éléments différents. Le guide officiel d'Android indique qu'un rapport de bug peut contenir des journaux système, des traces de pile, des sorties de diagnostic de services système, des journaux d'erreurs et des messages système émis par les applications utilisant la classe `Log` d'Android. Cela s'avère bien plus étendu qu'un enregistrement limité au plantage. Le contenu d'un rapport individuel dépend toujours de ce qui a été collecté et inclus. Consultez le [guide Android pour capturer et lire les rapports de bug](https://developer.android.com/studio/debug/bug-report).
Le rapport peut-il inclure le texte du journal intime ?
C'est possible sous certaines configurations, mais la simple présence d'un rapport de plantage n'établit pas qu'il inclut le texte des entrées. La question clé est de savoir ce que l'application enregistre en parallèle de l'incident et ce que le format du rapport capture.
Par exemple, les développeurs d'applications peuvent ajouter des messages de diagnostic ou des événements personnalisés. Si ces messages incluent une entrée de journal, un titre, un terme de recherche ou du texte copié depuis un éditeur, cette information pourrait être transmise avec l'événement. Sentry décrit les fils d'Ariane (breadcrumbs) comme une piste d'événements précédant un problème ; chacun peut comporter un message et des données structurées arbitraires. Les fils d'Ariane peuvent être collectés automatiquement par le biais d'intégrations activées ou ajoutés par une application. Consultez la [documentation de Sentry sur les fils d'Ariane](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). Les rapports de bug Android incluent également des journaux de messages système, qui peuvent contenir des messages écrits par les applications. Aucun de ces faits ne signifie que chaque application enregistre du texte privé : cela dépend de l'implémentation et de la configuration de l'application.
Que sont les journaux, les fils d'Ariane, les pièces jointes et le replay ?
Ces termes désignent des types distincts de données de diagnostic. Les journaux (logs) sont des messages enregistrés par l'application ou le système. Les fils d'Ariane (breadcrumbs) représentent une suite sélectionnée d'événements menant à une erreur, pouvant inclure des horodatages, des catégories, des messages et des données clé-valeur. Tous deux peuvent révéler davantage de contexte qu'une trace de pile, en fonction de ce que l'application enregistre.
Les pièces jointes sont des fichiers envoyés avec un événement, tels qu'un fichier journal, une capture d'écran ou un fichier de vidage mémoire (crash dump). Sentry souligne que les minidumps natifs peuvent contenir des éléments sensibles tels que des variables d'environnement, des chemins locaux ou des représentations en mémoire de champs de saisie. Sa documentation précise que les minidumps sont utilisés pour créer des événements et sont supprimés par défaut, mais peuvent être conservés en pièces jointes si ce paramètre est activé ; elle indique également que les pièces jointes ne sont pas couvertes par le nettoyage des données (data scrubbing) de Sentry. Consultez la documentation de Sentry sur les [données de plantage](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) et les [pièces jointes](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
La relecture de session (session replay) est une fonctionnalité distincte et optionnelle, et non un composant standard de chaque rapport de plantage. La documentation de Sentry sur le replay JavaScript décrit une reconstitution de type vidéo de l'activité du navigateur, y compris l'état du DOM et les interactions. Elle indique que le SDK masque par défaut le texte du DOM, les images et les saisies utilisateur, tout en offrant des options de configuration. Les paramètres de masquage et les plateformes prises en charge sont déterminants : ne déduisez pas que le contenu du journal est visible ou protégé sans vérifier la configuration réelle du fournisseur et ses paramètres de confidentialité. Consultez le [guide du Session Replay JavaScript de Sentry](https://docs.sentry.io/platforms/javascript/session-replay/).
Que devriez-vous vérifier avant de partager un rapport ?
Appliquez cette liste de contrôle au fichier réel ou à l'aperçu du rapport, et consultez la documentation de confidentialité de l'application ou du fournisseur lorsque le contenu du rapport n'est pas clair :
Cette liste de contrôle constitue un guide éditorial pratique pour l'utilisateur de journal intime qui examine un rapport avant de l'envoyer. Elle est distincte des instructions des concepteurs : les développeurs contrôlent leurs propres paramètres de journalisation, de replay et de pièces jointes, et doivent documenter ce que ces fonctionnalités collectent tout en vérifiant si les champs de diagnostic peuvent contenir des contenus saisis par l'utilisateur.
Pourquoi les rapports diffèrent-ils selon les applications et les appareils ?
Les systèmes d'exploitation génèrent des formats de rapports et des canaux de collecte différents ; les développeurs peuvent également utiliser un SDK tiers avec une configuration personnalisée. Apple indique que les rapports de plantage de l'App Store et de TestFlight sont accessibles via Xcode, tandis que d'autres journaux de diagnostic peuvent nécessiter d'être transférés depuis un appareil. Android fait la distinction entre les rapports de bug complets et les rapports de plantage fournis via des services comme Google Play ou Firebase. Les paramètres des fournisseurs peuvent également déterminer quels événements, fils d'Ariane, pièces jointes ou données de replay sont capturés et conservés. Fiez-vous à la politique de confidentialité de l'application et au rapport lui-même pour évaluer un cas précis, plutôt que de supposer que chaque service transmet les mêmes champs.