Permettre aux utilisateurs d'envoyer des photos dans votre application créée par IA (sans qu'elle s'effondre)

Le moment où votre application cesse d’être un simple champ de texte et laisse les gens envoyer une photo, quelque chose change. Ajouter l’envoi d’images et de fichiers signifie permettre à un utilisateur d’envoyer une photo, un reçu ou un document depuis son appareil vers votre application, qui le stocke et le réaffiche plus tard — une photo de profil, un reçu, une photo d’un colis abîmé, un contrat en PDF. C’est une de ces fonctionnalités qui ressemble à une simple case à cocher, mais qui cache en réalité quelques pièges. Aucun n’est difficile en soi. Mais ceux dont personne ne vous prévient sont justement ceux qui surgissent trois semaines après le lancement, généralement grâce à votre utilisateur le plus enthousiaste.

Voici un tour d’horizon de ce qui se passe réellement quand quelqu’un clique sur « envoyer », des trois erreurs qui reviennent vous mordre plus tard, et des demandes précises à faire à votre outil de création pour les éviter.

Que se passe-t-il réellement quand on envoie une photo dans une application ?

L’envoi d’une photo déclenche quatre étapes, dans l’ordre : votre téléphone transmet le fichier à l’application, l’application l’envoie vers un espace de stockage de fichiers séparé (pas la base de données), l’application enregistre un lien vers ce fichier à côté de l’enregistrement, puis récupère plus tard le fichier via ce lien chaque fois que quelqu’un consulte l’enregistrement.

Voici à quoi cela ressemble, étape par étape :

Le téléphone transmet le fichier à votre application. Une photo de téléphone moderne pèse souvent entre 4 et 12 mégaoctets. Ce n’est pas rien.
Votre application envoie ce fichier quelque part pour le stocker — pas dans la base de données de votre application, mais dans un espace de stockage séparé, conçu pour les fichiers.
Votre application enregistre un lien vers ce fichier dans la base de données, à côté du reste de l’enregistrement (ce reçu appartient à cette dépense).
Plus tard, quand quelqu’un consulte l’enregistrement, l’application récupère le fichier depuis le stockage grâce à ce lien et l’affiche.

Ce que les gens ratent, ce sont les étapes 2 et 3. Ils imaginent que la photo est « enregistrée dans l’application ». Ce n’est pas le cas, et ça ne devrait pas l’être. Les fichiers vivent dans le stockage ; votre base de données se contente de se souvenir où. Une fois cette séparation bien posée, tout ce qui suit devient plus simple.

Faut-il stocker les photos envoyées directement dans la base de données ?

Non — et c’est l’erreur la plus courante en matière d’envoi de fichiers, celle que les outils IA commettent parfois par défaut si vous n’êtes pas précis. Fourrer une photo de 10 Mo directement dans votre base de données, c’est comme ranger ses meubles dans son portefeuille. La base de données est conçue pour de petites données structurées — noms, dates, prix. Y déverser des photos, et elle ralentit, les sauvegardes gonflent, et un jour une page qui se chargeait instantanément met six secondes, parce qu’elle traîne avec elle une centaine d’images en pleine résolution.

Ce qu’il faut à la place : le fichier part vers un espace de stockage de fichiers (votre outil de création parlera peut-être de « bucket de stockage » ou de « blob storage »), et la base de données ne conserve que le lien. Demandez-le directement :

« Stocke les images envoyées dans un espace de stockage de fichiers, pas dans la base de données. Ne garde que l’URL du fichier dans l’enregistrement. »

Comment empêcher les utilisateurs d’envoyer le mauvais type de fichier ou un fichier trop lourd ?

Vous décidez à l’avance ce qui est autorisé — type de fichier, limite de taille, message d’erreur clair — et vous le précisez explicitement à votre outil de création, car sans ces règles, votre application acceptera n’importe quoi, y compris des fichiers qui bloquent l’envoi complètement. Deux situations réelles montrent pourquoi, toutes deux issues d’applications qui fonctionnaient très bien en test :

Une femme qui dirige une petite entreprise de traiteur a créé une application permettant à ses clients d’envoyer des photos de gâteaux qui leur plaisaient. Tout fonctionnait très bien jusqu’à ce qu’un client envoie une photo de 47 Mo, prise directement avec un appareil photo professionnel. L’envoi est resté bloqué, le client a abandonné, et elle a appris la nouvelle sous la forme : « ton application est cassée ». Elle n’était pas cassée — elle n’avait simplement jamais fixé de limite de taille, et elle est donc restée là, indéfiniment, à essayer d’avaler un fichier énorme.

Deuxième exemple : une freelance a créé un portail client où les gens envoient « leur logo ». Un client a envoyé un fichier .zip. Un autre a envoyé un PDF de 90 pages. L’application a tout accepté, parce que personne ne lui avait dit à quoi un logo était censé ressembler.

Décidez ces trois points à l’avance :

Quels types de fichiers ? Photos uniquement ? Alors acceptez les JPG et PNG et refusez le reste, avec un message aimable.
Quelle taille ? Une limite raisonnable pour une photo se situe autour de 5 à 10 Mo. Assez grande pour une vraie photo de téléphone, assez petite pour bloquer un déversement direct d’appareil photo.
Et si le fichier ne convient pas ? L’application doit le dire gentiment — « Merci d’envoyer un JPG ou un PNG de moins de 10 Mo » — plutôt que de simplement se figer.

Dites à votre outil de création :

« N’accepte que les images JPG et PNG jusqu’à 10 Mo. Si quelqu’un envoie autre chose ou un fichier trop lourd, affiche un message clair au lieu d’échouer silencieusement. »

Pourquoi votre application ralentit-elle quand elle contient beaucoup de photos ?

Parce qu’à chaque consultation, chaque visiteur télécharge l’original en pleine résolution, jamais une version réduite — sur son téléphone, avec son forfait data, à chaque fois qu’il ouvre l’enregistrement. Prenons quelqu’un qui envoie une photo nette de 8 Mo : toute seule, elle fonctionne très bien. Mais multipliez cela par une galerie de vingt photos, et votre application rapide se met soudain à patauger.

La solution porte un nom qu’il vaut la peine de connaître, car votre outil de création le reconnaîtra : une miniature, ou une version redimensionnée. L’idée est de conserver l’original tout en créant aussi une petite copie adaptée au web, et d’afficher cette petite copie dans les listes et les aperçus. L’image complète ne se charge que lorsque quelqu’un souhaite réellement la voir en grand.

« Quand une image est envoyée, crée aussi une version redimensionnée plus petite pour les aperçus et les listes. Affiche la petite version par défaut, et ne charge l’image complète que lorsqu’on clique pour la voir. »

Vous n’avez pas besoin de comprendre comment cela se fait. Vous devez juste savoir que ça existe, pour pouvoir le demander avant que votre application ne ralentisse — pas après.

Quelques réglages plus discrets, mais qui valent le coup

Ces trois décisions ne casseront pas votre application si vous les négligez, mais elles coûtent moins cher à prendre maintenant qu’à corriger plus tard : qui peut voir le fichier, ce qu’il advient de lui quand l’enregistrement est supprimé, et si l’envoi fonctionne depuis un téléphone.

Qui peut voir le fichier ? Une photo de profil, tout le monde peut la voir. Une pièce d’identité scannée ou un contrat signé, non. Si le fichier est privé, dites à votre outil de création que le lien doit exiger une connexion, et non être une URL publique que n’importe qui peut ouvrir. C’est le point sur lequel j’insisterais le plus pour tout ce qui est sensible.
Que se passe-t-il quand l’enregistrement est supprimé ? Si quelqu’un supprime une dépense, la photo du reçu doit-elle disparaître aussi ? Sinon, vous accumulez peu à peu des fichiers orphelins que vous payez pour stocker, et dont vous avez oublié l’existence.
Est-ce que ça fonctionne sur téléphone ? La plupart des envois se font depuis un téléphone, qui propose à la fois « prendre une photo maintenant » et « choisir dans la galerie ». Testez les deux sur un vrai téléphone, pas seulement sur votre ordinateur portable, où l’on se contente de glisser un fichier.

Testez-la comme le ferait un inconnu

Testez-la en essayant volontairement de la casser, comme le fera par accident un vrai utilisateur — une photo normale, un fichier trop lourd, le mauvais type de fichier, un envoi en direct depuis l’appareil photo du téléphone, et une suppression — avant de la considérer terminée :

Envoyez une photo de téléphone normale. Apparaît-elle, et l’aperçu se charge-t-il rapidement ?
Envoyez un fichier énorme. L’application vous arrête-t-elle avec un message clair, ou reste-t-elle bloquée ?
Envoyez le mauvais type de fichier — un PDF là où une photo est attendue. Explique-t-elle la règle ?
Ouvrez l’application sur votre téléphone et envoyez directement depuis l’appareil photo.
Supprimez un enregistrement et vérifiez si son fichier est traité comme vous l’aviez décidé.

Si ces cinq points se comportent correctement, vous avez évacué les pièges qui piègent la plupart des gens.

Les envois de fichiers font partie de ces fonctionnalités où l’écart entre « ça marche dans la démo » et « ça marche pour un inconnu dans un train avec une photo de chat de 12 Mo » se résume exactement à l’ensemble des décisions ci-dessus. Aucune n’est difficile. Elles sont juste faciles à négliger — et bien plus simples à demander maintenant qu’à réparer plus tard.

Si vous repoussiez l’ajout des envois de fichiers parce que ça vous semblait un grand saut technique, ce n’en est pas un. Ouvrez votre outil de création, demandez un stockage d’images avec une limite de taille et une miniature, et observez ce qu’il vous donne. Puis allez essayer de le casser depuis votre téléphone — c’est le vrai test, et il ne prend que cinq minutes.