LLDB

LLDB : Débogueur des plateformes Apple, capable d’inspecter l’état du programme et d’évaluer des expressions en cours d’exécution.

Famille « Développement ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

Pourquoi LLDB compte sur un projet mobile

LLDB fait partie des notions invisibles à l’usage et bien réelles dans la facture. Ce point décide de la facilité avec laquelle une équipe reprendra le code dans deux ans, avec d’autres développeurs.

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.

Ce que ça devient dans un cahier des charges

Le cahier des charges gagne à formuler « LLDB » en résultat attendu plutôt qu’en solution : ce que l’application doit savoir faire, à quel moment, et comment on le vérifiera à la recette.

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

• Les versions minimales d’iOS et d’Android supportées, qui décident des API disponibles.
• Le sort du code : dépôt remis, licences des bibliothèques, cession des droits à la livraison.
• Les bibliothèques tierces autorisées, et qui paie leurs licences dans la durée.
• La procédure de mise à jour de l’application une fois qu’elle est publiée.

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.

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.

Les contrôles à prévoir

Le contrôle de « LLDB » se prépare avant la livraison. Un critère écrit après coup se négocie ; un critère écrit avant se coche.

• Vérifier que le projet se compile chez quelqu’un d’autre, à partir du dépôt seul.
• Lire le rapport de tests automatisés fourni avec la livraison.
• Vérifier que les clés de signature et les comptes de service sont remis, pas seulement promis.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Les pièges à éviter

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Laisser la remise du code hors du contrat, puis découvrir que le dépôt n’est pas transmis.
• Confondre bibliothèque gratuite et bibliothèque sans coût : certaines licences se paient à l’usage.
• Croire qu’un développeur reprend le travail d’un autre sans documentation ni période de recouvrement.
• Traiter la dette technique comme une affaire interne à l’agence : elle sera facturée au suivant.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

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

• itérateur
• xcconfig
• Flutter
• React Native
• Swift

Questions fréquentes

LLDB : de quoi parle-t-on exactement ?

Débogueur des plateformes Apple, capable d’inspecter l’état du programme et d’évaluer des expressions en cours d’exécution. 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.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

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