Lorsque votre bot devient viral : se développer du jour au lendemain

Notre bot Slack a géré 200 messages par jour pendant trois mois sans problème. Puis un blogueur technologique en a parlé dans une newsletter, et nous sommes passés de 200 à 12 000 messages en 48 heures.

Tout a cessé de fonctionner. Pas de manière spectaculaire — le serveur n’a pas pris feu ni rien. Il a simplement… ralenti. Et a continué à ralentir. Puis a commencé à perdre des messages. Et ensuite est devenu complètement silencieux pendant que 12 000 personnes se demandaient pourquoi le bot IA dont elles venaient d’entendre parler ne répondait pas.

Voici ce qui s’est passé, ce que nous avons fait et comment nous sommes passés de « projet secondaire amusant » à « chose dont les gens dépendent réellement » en une semaine.

Les 6 premières heures : déni et panique

La newsletter est arrivée dans les boîtes de réception à 9h00 un mardi. À 10h00, notre file d’attente de messages avait un retard de 400 messages. À midi, la file atteignait 2 000 et le temps de réponse était de 45 secondes (normalement moins de 3 secondes).

Ma première réaction : « Hmm, c’est beaucoup de messages. » Ma seconde réaction, 20 minutes plus tard : « Oh non. »

Le goulet d’étranglement n’était pas le CPU ou la mémoire — c’était l’API du modèle d’IA. Chaque message nécessitait un appel API, et nous atteignions rapidement les limites de taux. Notre plan API gratuit permettait 60 requêtes par minute. Nous avions besoin de plus de 200 par minute.

Solution rapide : mise à niveau du plan API. Nous avons porté notre limite à 500 requêtes par minute en 30 minutes en passant à un plan payant. La file d’attente a commencé à se vider. Crise partiellement évitée.

Mais ensuite, la seconde vague est arrivée.

Heures 6-24 : tout le reste tombe en panne

Augmenter le débit API a révélé tous les autres goulets d’étranglement que nous n’avions pas remarqués à faible volume.

Connexions à la base de données saturées. Chaque message déclenchait une recherche dans la base de données pour le contexte utilisateur. À 200 messages/jour, pas de problème. À 12 000, notre pool de connexions était épuisé. Les utilisateurs recevaient des erreurs « service indisponible ».

Correction : augmentation de la taille du pool de connexions, ajout de l’optimisation de connexions avec PgBouncer, et mise en place de répliques de lecture pour les recherches de contexte.

Fuite de mémoire dans le gestionnaire de messages. Une variable qui stockait le contexte de la conversation croissait sans être nettoyée. À faible volume, elle grandissait lentement et était purgée par des redémarrages occasionnels. À fort volume, elle consommait toute la mémoire disponible en environ 4 heures.

Correction : ajout d’un nettoyage approprié après le traitement de chaque message. Ce bug était présent depuis le premier jour — il n’avait jamais eu d’importance jusqu’à maintenant.

Traitement mono-thread. Les messages étaient traités séquentiellement. Un à la fois. À 200 messages/jour, cela allait. À 12 000, cela signifiait que chaque message attendait derrière chaque autre message.

Correction : mise en œuvre d’un traitement concurrent avec une file d’attente de tâches appropriée. Les messages sont distribués entre plusieurs travailleurs. Cela a réduit le temps de réponse moyen de 45 secondes à moins de 5.

Le moment « Oh, nous avons besoin d’une véritable infrastructure »

Au bout de 24 heures, j’ai réalisé que notre architecture « ça fonctionne sur un VPS à 10 $/mois » ne pourrait pas gérer une croissance soutenue. Nous avions besoin de :

Un véritable équilibreur de charge. Pas parce que nous avions besoin de plusieurs serveurs encore, mais parce que nous avions besoin de vérifications de l’état, de redémarrages automatiques et de la capacité à déployer des mises à jour sans temps d’arrêt.

Une file d’attente de messages. File d’attente de tâches soutenue par Redis qui découple la réception des messages du traitement des messages. Si le modèle IA est lent, les messages attendent dans la file d’attente au lieu de mourir dans les délais d’attente. Si un travailleur plante, le message est retenté au lieu d’être perdu.

Surveillance qui alerte réellement. Nous avions des journaux. Nous n’avions pas d’alerte. La différence est importante quand les choses tombent en panne à 2h du matin et que personne ne surveille les journaux.

Scalabilité horizontale. La capacité d’ajouter plus de travailleurs lorsque la charge augmente. Notre architecture se redimensionne automatiquement : si la profondeur de la file d’attente dépasse un seuil, de nouveaux travailleurs se mettent en place automatiquement.

Ce que nous avons réalisé en une semaine

Jour 1-2 : mise à niveau d’urgence de la limite de taux, correction du pool de connexions, correction de la fuite de mémoire.
Jour 3-4 : mise en œuvre de la file d’attente de messages, traitement concurrent.
Jour 5-6 : équilibreur de charge, surveillance avec alertes, scalabilité horizontale.
Jour 7 : enfin dormi.

Le coût total de l’infrastructure est passé de 10 $/mois à environ 120 $/mois. Mais nous sommes passés de 200 messages/jour à gérer confortablement 50 000. Et l’architecture peut encore s’adapter simplement en ajoutant des travailleurs.

La liste de vérification de scalabilité que j’aurais aimé avoir

Si votre bot IA prend de l’ampleur et que vous voulez être prêt avant que le pic n’arrive :

Configurez la surveillance avec des alertes maintenant. Temps de réponse, taux d’erreurs, profondeur de la file d’attente, utilisation de la mémoire. Seuils d’alerte à 2x les valeurs normales. Vous voulez être au courant des problèmes avant que les utilisateurs ne vous le signalent.

Mettez en œuvre une file d’attente de messages. Même à faible volume. Cela découple la réception du traitement, permet des réessais et rend la scalabilité horizontale triviale plus tard.

Analysez votre utilisation des ressources par message. Combien de requêtes de base de données par message ? Combien de mémoire ? Combien d’appels API ? Multipliez ces chiffres par votre objectif de croissance et voyez où se trouvent les goulets d’étranglement.

Testez à 10 fois votre charge actuelle. Utilisez un outil de test de charge pour simuler un volume de messages multiplié par 10 pendant une heure. Regardez ce qui tombe en panne. Corrigez-le avant qu’il ne tombe en panne en production.

Ayez un plan de montée en charge documenté. « Si le trafic double, faites ces trois choses. » Avoir le plan écrit signifie que vous pouvez l’exécuter à 2h du matin quand vous êtes à moitié endormi au lieu d’essayer de concevoir des solutions sous pression.

Ce que j’ai appris sur l’IA à grande échelle

Le modèle IA n’est généralement pas le goulet d’étranglement — tout ce qui l’entoure l’est. Requêtes de base de données, gestion de contexte, formatage de sortie, acheminement des messages — toute l’infrastructure « ennuyeuse » que vous omettez lors de la construction d’un prototype. À grande échelle, les éléments ennuyeux sont plus importants que les éléments d’IA.

Aussi : les limites de taux sont la contrainte de scalabilité la plus sous-estimée dans les applications IA. Votre architecture brillante n’a pas d’importance si l’API du modèle ne permet que 60 requêtes par minute. Vérifiez vos limites avant de lancer, et ayez un plan pour quand vous les dépassez.

Le pic viral a été stressant mais finalement positif. Cela nous a forcés à construire l’infrastructure que nous aurions dû mettre en place dès le départ. Et maintenant, nous sommes prêts pour le prochain pic — quand il arrivera.

🕒 Published: March 26, 2026