dSYM

dSYM : Fichier de symboles associé à un binaire, sans lequel un rapport de plantage reste une suite d’adresses illisibles.

Ce terme appartient à la famille « Développement ». La page reprend l’essentiel : à quoi ça sert, comment l’écrire, ce qui se passe quand on l’oublie.

Ce que recouvre dSYM, concrètement

Sur un projet mobile, dSYM relève des choix de fabrication. Ce n’est pas une fonctionnalité que l’utilisateur verra à l’écran, mais une décision technique qui conditionne le coût des évolutions suivantes.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

La traduction en exigences

Dans un cahier des charges, dSYM n’a pas à être imposé ligne à ligne. Ce qui doit être écrit, c’est l’exigence à laquelle ce choix répond et la contrainte qu’il ne doit pas violer.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le niveau de tests automatisés attendu, et ce qui déclenche un refus de recette.
• La documentation technique livrée, et à qui elle doit permettre de reprendre le projet.
• L’environnement de recette, distinct de la production, et la liste de ceux qui y accèdent.
• Le format de livraison des sources, des comptes de service et des clés de signature.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Ce que ça change au moment de la recette

dSYM ne se voit pas à l’usage. C’est pour cette raison qu’il faut le vérifier explicitement, sinon personne ne le fera.

• Lancer l’application sur un appareil ancien, pas seulement sur le dernier modèle.
• Contrôler la liste des bibliothèques tierces et le régime de leurs licences.
• Suivre soi-même, une fois, la documentation d’installation remise.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

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.

• Imposer une technologie dans le cahier des charges sans écrire le besoin qu’elle sert.
• Accepter un devis où le développement iOS et le développement Android tiennent dans une seule ligne.
• Repousser les tests automatisés à la fin du projet, c’est-à-dire ne jamais les écrire.
• Changer de socle technique en cours de route sans rechiffrer le reste du planning.
• Employer le mot sans le définir, et laisser chaque partie prenante y mettre son propre sens.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Task
• Flutter
• React Native
• Swift
• Kotlin

Questions fréquentes

Qu’est-ce que « dSYM » ?

Fichier de symboles associé à un binaire, sans lequel un rapport de plantage reste une suite d’adresses illisibles. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Faut-il l’imposer dans le cahier des charges ?

Écrivez le besoin et la contrainte, pas la solution. Si un choix technique précis est indispensable, à cause de l’existant ou des compétences internes, justifiez-le en une phrase : un prestataire pourra le respecter, ou proposer mieux avec un argument.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.