Compression d’image

Compression d’image : Réduction du poids d’un visuel avant envoi ou stockage, arbitrage permanent entre netteté perçue et volume transféré.

Classé dans la famille « Technique », 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.

Pourquoi Compression d’image compte sur un projet mobile

Compression d’image appartient à la plomberie de l’application, la partie que personne ne montre en démonstration et qui explique pourtant une bonne moitié des retards.

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.

Comment l’écrire dans un cahier des charges

Écrire « Compression d’image » dans un cahier des charges ne suffit pas. Il faut préciser le comportement attendu quand ça tombe en panne, parce que c’est ce cas-là que les utilisateurs vivront.

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

• Les intégrations tierces, nommées, avec leur documentation et leurs limites d’appel.
• La sauvegarde des données : fréquence, durée de rétention, restauration réellement testée.
• La supervision : quelles alertes, vers qui, sous quel délai d’intervention.
• Le sort des données à la fin du contrat, format d’export compris.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

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.

Ce que ça change au moment de la recette

Compression d’image se vérifie en conditions dégradées, pas en conditions idéales. C’est là que les écarts apparaissent.

• Demander une restauration de sauvegarde réellement exécutée, avec sa date.
• Déclencher une alerte pour vérifier qu’elle arrive bien à quelqu’un.
• Demander la facture d’hébergement du mois, pour éviter la découverte à six mois.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

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.

• Dimensionner l’infrastructure sur le trafic du lancement et non sur celui d’une campagne.
• Considérer les sauvegardes comme faites parce qu’elles sont configurées, sans tester de restauration.
• Découvrir les coûts d’hébergement après la mise en ligne, faute de les avoir demandés au devis.
• Mesurer la performance sur un téléphone récent et l’annoncer comme celle du parc réel.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

Termes liés

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

• Backend
• Scalabilité horizontale
• API REST
• Webhook
• Notification push

Questions fréquentes

Qu’est-ce que « Compression d’image » ?

Réduction du poids d’un visuel avant envoi ou stockage, arbitrage permanent entre netteté perçue et volume transféré. 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.

Qui vérifie que c’est bien fait ?

Le client, à la recette, avec un critère écrit à l’avance. À défaut, personne : ces sujets ne se voient pas à l’écran, et un utilisateur ne signale que leurs conséquences.

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.