Votre appli créée avec l'IA vient d'être mise en avant. Survivra-t-elle au pic de trafic ?

Imaginez la bonne version d’une mauvaise journée. Vous avez publié votre appli créée avec l’IA dans une communauté dont vous faites partie, ou bien quelqu’un avec une grande audience l’a essayée et partagée, ou encore elle s’est retrouvée en première page d’un forum auquel vous ne l’aviez même pas soumise. Soudain, le mince filet de visiteurs auquel vous êtes habitué se transforme en torrent. Mille personnes, toutes en train de cliquer partout dans la même heure.

C’est le moment pour lequel vous avez créé tout ça. C’est aussi le moment où beaucoup d’applis créées avec l’IA s’écroulent discrètement — pages lentes, roues qui tournent à l’infini, un formulaire d’inscription qui refuse de s’envoyer. Les gens qui ont fini par venir se heurtent à un mur et repartent, et la plupart ne reviendront jamais réessayer.

La bonne nouvelle : survivre à un pic de trafic, c’est surtout une poignée de décisions ennuyeuses que vous pouvez prendre avant que le pic n’arrive. Pas besoin d’être ingénieur. Il faut juste savoir quels raccourcis ne pas prendre.

Ce qui casse vraiment quand le trafic explose

Quand cent fois le nombre habituel de gens utilisent votre appli en même temps, les choses ne cassent pas au hasard. Elles cassent dans un ordre prévisible, et c’est presque toujours aux trois mêmes endroits.

La base de données est débordée. Chaque fois que quelqu’un charge une page, votre appli pose en général une question à sa base de données : « quelles sont les données de cet utilisateur ? » Une seule personne qui pose la question, ce n’est rien. Mille personnes qui posent la même question dans la même minute peuvent s’accumuler plus vite que la base ne peut répondre, et la page de tout le monde ralentit jusqu’à se traîner.

Quelque chose en dehors de votre appli devient lent. La plupart des applis créées avec l’IA s’appuient sur d’autres services — envoyer des e-mails, traiter des paiements, appeler un modèle d’IA. Ces services limitent souvent la vitesse à laquelle vous pouvez les solliciter. En trafic normal, vous ne remarquez jamais cette limite. Sous un pic, votre appli l’atteint, et soudain chaque action qui touche ce service se bloque.

L’appli refait sans cesse le même travail coûteux. Si votre page d’accueil exécute un calcul lourd à chaque visite — récupérer une liste, la classer, la mettre en forme — c’est très bien pour dix visiteurs et brutal pour mille. Ce travail a toujours été du gaspillage. Le faible trafic le masquait, c’est tout.

Vous remarquez le schéma : aucun de ces problèmes n’est un nouveau bug. Le pic n’a rien cassé. Il a révélé des faiblesses qui étaient déjà là, tranquilles, sous le faible trafic.

La correction la moins chère : mettre en cache ce qui ne change pas

La mise en cache a l’air technique, mais l’idée est simple : si la réponse à une question est la même pour tout le monde et qu’elle change rarement, calculez-la une fois et réutilisez-la au lieu de refaire le travail pour chaque visiteur.

Votre page d’accueil est probablement identique pour les 1 000 personnes qui la chargent. Alors pourquoi demander à la base de données de la reconstruire 1 000 fois ? Construisez-la une fois, sauvegardez le résultat quelques minutes, et servez cette copie sauvegardée à tout le monde. Vous venez de transformer mille requêtes coûteuses vers la base en une seule.

Dites exactement ça à votre créateur d’applis avec IA : « Mets en cache la page d’accueil et la liste publique des produits pendant cinq minutes pour qu’on ne sollicite pas la base à chaque visite. » Tout ce qui est identique pour tout le monde et n’a pas besoin d’être à la seconde près — une page de tarifs, une liste publique, un index de blog — est candidat à la mise en cache. Le contenu personnalisé (le tableau de bord de chacun, les réglages de son compte) ne peut pas être mis en cache de la même façon, mais ça représente en général une petite part du trafic pendant un pic. La plupart des gens regardent les mêmes quelques pages publiques.

Ne faites pas attendre les gens pour des choses qui peuvent se faire plus tard

Voici une erreur facile à commettre et facile à corriger. Disons que quelqu’un s’inscrit, et que votre appli lui envoie un e-mail de bienvenue. Si votre appli le fait attendre sur la page d’inscription jusqu’à ce que l’e-mail soit complètement envoyé, alors un service d’e-mail lent rend votre inscription lente — au moment précis où le plus de gens s’inscrivent.

La solution est de laisser les choses lentes se faire en arrière-plan. La personne voit « Vous êtes inscrit ! » instantanément, et l’e-mail part quelques secondes plus tard sans que personne n’ait à l’attendre. Même résultat, mais le visiteur ne fixe pas une roue qui tourne pendant qu’un serveur de messagerie à trois entreprises de là prend son temps.

Demandez à votre créateur d’applis : « Envoie l’e-mail de bienvenue en arrière-plan pour que l’inscription n’ait pas à l’attendre. » La même logique s’applique à tout ce qui n’a pas besoin de se terminer avant que la personne puisse continuer — générer un rapport, synchroniser avec un autre outil, envoyer une notification. Si l’utilisateur n’a pas besoin du résultat tout de suite, ne le faites pas attendre.

Prévoyez un plan « trop de monde »

Parfois le pic est plus gros que tout ce que vous aviez préparé, et le geste honnête est de se dégrader élégamment plutôt que de s’effondrer. Une appli lente qui fonctionne encore vaut mieux qu’une appli cassée.

Quelques versions simples de ce principe :

• Un message d’attente sympathique. Si quelque chose est vraiment surchargé, afficher « Nous recevons beaucoup de visiteurs en ce moment — patientez un instant » vaut bien mieux qu’un écran blanc ou une erreur brute. Les gens pardonnent à une appli débordée. Ils ne pardonnent pas à une appli cassée.
• Désactivez temporairement la fonctionnalité la plus lourde. Si une fonctionnalité est la coûteuse — par exemple une génération par IA qui coûte du vrai argent et du temps à chaque clic — vous pouvez la masquer pendant la déferlante et garder le reste de l’appli rapide. La plupart des visiteurs, pendant un pic, sont en train de parcourir, pas d’utiliser votre fonctionnalité la plus exigeante de toute façon.
• Sachez d’où vient votre facture. Si votre appli appelle un modèle d’IA payant à chaque visite, mille visiteurs peuvent signifier une facture surprise, et pas seulement une page lente. Savoir quelles actions coûtent de l’argent vous permet de décider à l’avance ce que vous voulez plafonner.

Une répétition générale de trente minutes

Pas besoin d’outils sophistiqués pour trouver vos points faibles. Il vous faut quelques amis et une demi-heure.

Demandez à cinq ou six personnes d’ouvrir votre appli au même moment et de cliquer partout sans ménagement pendant quelques minutes — s’inscrire, utiliser la fonctionnalité principale, charger les pages chargées. C’est rudimentaire, mais ça fait remonter vite l’évident. Si l’appli semble déjà poussive avec six personnes qui la malmènent, mille la mettront à plat. Si elle reste réactive, vous avez au moins franchi la barre minimale.

Pendant qu’ils cliquent, observez quelle page paraît la plus lente. Cette page lente est exactement là où un vrai pic de trafic fera le plus mal, et c’est la première chose à mettre en cache ou à simplifier. Vous n’essayez pas de simuler mille utilisateurs. Vous essayez de trouver l’unique page qui peine déjà à six.

Le vrai objectif

Vous ne pouvez pas rendre votre appli infiniment à l’épreuve des balles, et vous n’en avez pas besoin. Le but n’est pas de gérer dix mille personnes sans accroc dès votre premier moment viral. C’est de ne pas vous ridiculiser devant les quelques centaines qui ont fini par venir — de vous assurer que les gens que vous avez tant travaillé à attirer trouvent une appli qui fonctionne plutôt qu’une roue qui tourne.

Mettez en cache les pages qui ne changent pas. Déplacez le lent en arrière-plan. Prévoyez un plan « trop de monde ». Faites une répétition générale à cinq amis avant d’en avoir besoin. Rien de tout ça n’exige d’écrire du code vous-même — juste de savoir quoi demander à votre créateur d’applis avec IA.

Ainsi, quand votre moment arrivera, vous pourrez en profiter au lieu de déboguer frénétiquement. Voici donc la question qui mérite réflexion cette semaine : si mille personnes débarquaient demain, quelle page casserait en premier — et le savez-vous déjà ?