thread principal

thread principal : Fil d’exécution qui dessine l’interface, à ne jamais bloquer sous peine de gel visible immédiatement par l’utilisateur.

Entrée de la famille « Développement » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

Ce que recouvre thread principal, concrètement

thread principal appartient au vocabulaire courant des équipes qui écrivent l’application. Le mot circule dans les revues de code, les tickets et les estimations, et un malentendu à ce niveau se paie en jours de développement.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

Comment l’écrire dans un cahier des charges

Un cahier des charges qui mentionne « thread principal » doit dire pourquoi. Sans justification écrite, la mention devient une préférence technique que personne ne saura arbitrer six mois plus tard.

À é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.

Vérifier plutôt que croire

Le contrôle de « thread principal » 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.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Les pièges à éviter

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• 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 :

• ObservableObject
• Goulot d’étranglement
• Flutter
• React Native
• Swift

Questions fréquentes

thread principal : de quoi parle-t-on exactement ?

Fil d’exécution qui dessine l’interface, à ne jamais bloquer sous peine de gel visible immédiatement par l’utilisateur. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

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.