squash

squash : Fusion de plusieurs commits en un seul avant intégration, pratique pour garder un historique lisible sur la branche principale.

Classé dans la famille « Développement », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

Ce que recouvre squash, concrètement

squash 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.

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

Un cahier des charges qui mentionne « squash » 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 :

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

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.

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.

Comment le vérifier à la recette

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

• Demander à voir le dépôt de code et son historique, pas une capture d’écran.
• 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.

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.

Ce qui tourne mal le plus souvent

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

• 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.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

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

• Kotlin
• exception
• Faux point d’accès

Questions fréquentes

squash : de quoi parle-t-on exactement ?

Fusion de plusieurs commits en un seul avant intégration, pratique pour garder un historique lisible sur la branche principale. 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.

Comment vérifier qu’une agence maîtrise le sujet ?

Demandez un exemple tiré d’un projet livré, pas une définition. L’écart entre les deux réponses se voit en trente secondes, et il est plus parlant qu’une liste de technologies sur un site vitrine.

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.