La plupart des formulaires d’envoi annoncent tous leurs échecs avec la même phrase. Ce message unique cache au moins quatre contrôles différents, et la solution n’est pas la même pour chacun.
Contrôle n° 1 : la limite de poids
Le plafond le plus courant, et le seul auquel on pense d’ordinaire. Il se mesure en octets, pas en mégapixels ; une image qui a l’air petite mais qui sort d’un téléphone récent peut donc très bien échouer.
Corrigez-le en compressant vers un nombre inférieur au plafond annoncé — pas exactement dessus. Certains systèmes mesurent la requête encodée plutôt que le fichier, et un envoi encodé en base64 au passage pèse environ un tiers de plus que le fichier sur le disque. Viser quelques pour cent sous le plafond ne vous coûte presque rien et élimine toute la question.
Contrôle n° 2 : la limite de dimensions
Indépendante du poids du fichier, et souvent non documentée. Un formulaire peut exiger une photo qui ne dépasse pas 1200 pixels de large, aussi léger que soit le fichier. Compresser davantage ne le satisfera jamais — il faut redimensionner. Si le formulaire annonce une taille d’affichage, il impose généralement aussi un maximum proche de celle-ci.
Contrôle n° 3 : le type MIME
Les serveurs prudents ne font pas confiance à l’extension du fichier ; ils lisent les premiers octets
et identifient le format à sa signature. Renommez un PNG en .jpg et un serveur strict voit toujours
un PNG, parce que c’est ce que disent les octets.
C’est pour cela que convertir compte et que renommer ne sert à rien. C’est aussi pour cela qu’un fichier exporté en « JPEG » depuis un outil de design peut échouer ; certains exportateurs écrivent une variante que la bibliothèque du serveur refuse.
Contrôle n° 4 : espace colorimétrique et variante d’encodage
Plus rare, mais bien réel. Les JPEG en CMJN, les PNG 16 bits et les JPEG progressifs sont tous des fichiers valides que certaines bibliothèques serveur anciennes refusent purement et simplement.
Le réencodage corrige ceux qu’il peut atteindre. ToolZool décode en pixels 8 bits simples et écrit du JPEG de base par défaut ; un PNG 16 bits ressort donc en 8 bits et un JPEG progressif ressort en JPEG de base — les deux variantes qu’un serveur difficile a le plus de chances d’accepter. Le JPEG en CMJN est le cas épineux ; c’est un fichier de chaîne d’impression, pas un fichier web, et la correction fiable consiste à le réexporter en RVB depuis ce qui l’a produit.
Comment les distinguer
Essayez une image de test volontairement minuscule : quelques kilooctets, quelques centaines de pixels, un JPEG de base tout simple. Si elle passe, le problème vient de votre fichier et vous savez désormais quel axe changer — commencez par le compresseur, et si la limite est serrée, tenir une limite de 50 KB indique dans quel ordre changer les choses. Si l’image de test échoue elle aussi, le problème vient du formulaire, de la session ou du navigateur, et aucun réencodage n’y changera quoi que ce soit.
