Un bot vidéo créé en vibe coding a craqué dès le deuxième utilisateur : comment il est passé à six VPS

Le vibe coding fonctionne très bien tant que le projet n’a qu’un utilisateur et que cet utilisateur, c’est vous. Sur Habr, un développeur d’UNIQ a raconté comment un bot Telegram créé par un ami avec l’aide de l’IA s’est transformé en un service commercialisable sans rougir. Principal enseignement : écrire le code va vite, mais c’est à vous de définir le comportement attendu du système.

Le point de départ et les premières défaillances

UNIQ reçoit une vidéo et en produit une à dix versions destinées à être republiées : FFmpeg modifie les paramètres de l’image, du tempo, des couleurs et du son. Le prototype était écrit en Python, utilisait SQLite et tournait sur le Mac de son créateur. Le premier problème a été le disque : pour une même commande, le fichier source, les fichiers temporaires et les copies terminées coexistent. Les développeurs ont donc ajouté une limite d’envoi de 150 Mo, un budget d’espace disque et un mécanisme de nettoyage.

Le véritable tournant est arrivé lorsqu’un deuxième utilisateur a participé aux tests. Pendant que FFmpeg traitait la vidéo d’une autre personne, il ouvrait le menu et envoyait sa propre vidéo. Tout se heurtait alors aux verrous globaux et à un état dispersé dans le code. Les développeurs n’ont pas réécrit le service en Go : changer de langage ne supprime pas un verrou global et n’ajoute pas de cœurs. Ils ont plutôt séparé les attentes réseau, les requêtes à la base de données et l’encodage.

Une file d’attente qui résiste aux pannes

Pour répartir les tâches entre plusieurs serveurs, ils ont choisi PostgreSQL : une base commune, des transactions et des verrous de lignes via FOR UPDATE SKIP LOCKED. Chaque tâche est confiée à un worker pour une durée limitée, sous forme de bail. Si le worker se bloque, un autre reprend la commande à l’expiration de ce bail. Pour empêcher le premier worker d’écraser le résultat lorsqu’il reprend son activité, un nouveau jeton de propriétaire est créé à chaque attribution et vérifié à chaque écriture de l’état.

Le plan des effets est enregistré à l’avance, et les copies terminées sont consignées dans un point de reprise, ou checkpoint. Le deuxième worker peut ainsi reprendre là où le précédent s’est arrêté. Une nouvelle requête portant le même identifiant renvoie le reçu enregistré au lieu de répéter l’opération. Les développeurs précisent aussi franchement la limite du dispositif : si le fichier a été envoyé à Telegram, mais que l’enregistrement de cet envoi n’a pas eu le temps d’être sauvegardé, la copie peut être livrée deux fois. L’idempotence interne ne confère pas à une API externe une garantie d’exécution exactement une fois, dite exactly-once.

Les crédits ont posé un autre problème. Leur gestion s’est révélée être une petite comptabilité, avec des lots ayant chacun leur date d’expiration, des réservations et un historique des opérations. Lorsqu’une commande est annulée, les crédits inutilisés retournent dans leurs lots d’origine en conservant leur date d’expiration. Sinon, l’annulation devient un abonnement sans fin. La commande fige le tarif au moment de sa confirmation, et une notification de paiement répétée ne déclenche pas un deuxième crédit, grâce à l’identifiant unique de la transaction externe.

Le gain perceptible pour l’utilisateur est venu d’une réorganisation plutôt que d’une optimisation : l’encodage a été séparé de la livraison, et les copies sont envoyées une par une. Lors d’un essai sur un banc de test local, elles sont arrivées après 40, 70, 105, 136 et 171 secondes. La première était donc disponible 131 secondes avant la fin de la commande.

Les chiffres de charge et leurs limites

Après avoir déplacé les vidéos vers S3 et ajouté PgBouncer, avec jusqu’à 2000 connexions clientes pour 10 connexions serveur, les développeurs ont commencé à mesurer les goulets d’étranglement. Une vague de 1000 confirmations de commande prenait 5,9 secondes, tandis que le temps d’attente cumulé sur un seul verrou SQL atteignait environ quarante secondes. Le verrou exclusif global a été remplacé par des verrous par utilisateur, ramenant la durée de la vague à 3,2 secondes.

Faire passer le pool de l’application de 8 à 16 connexions, alors que PgBouncer était limité à 10, n’a rien accéléré : la file d’attente s’est simplement déplacée. L’encodage de 20 vidéos courtes en 720×1280 sur 5 CPU a atteint un plateau dès 4–5 workers, à environ 29 tâches par minute. Douze processus consommaient 3133 Mio de mémoire et travaillaient plus lentement que cinq.

Les 10 000 premières sollicitations du menu ont été traitées sans erreur, mais le p95 atteignait environ 30 secondes. Comme le soulignent à juste titre les développeurs, accepter une requête et répondre rapidement à une personne sont deux choses différentes.

Les enseignements à en tirer

Ces chiffres ont été mesurés sur des vidéos courtes et sur un banc de test précis. Ils ne peuvent être extrapolés à de longues vidéos en 1080p ni à un nombre d’utilisateurs. En revanche, les questions à se poser sont universelles. Qui bloque qui ? Où réside l’état ? Que se passe-t-il si un worker meurt au milieu d’une commande ? Que se passe-t-il lorsqu’un événement de paiement est reçu une deuxième fois ? L’IA écrit vite le code, mais c’est à vous de formuler les réponses à ces questions et de les vérifier par des tests, de préférence avant l’arrivée du deuxième utilisateur.