Dans le monde effervescent de la technologie et de l’intelligence artificielle, les startups s’appuient de plus en plus sur des outils automatisés pour accélérer leur développement. Cependant, cette dépendance peut parfois se retourner contre elles, comme l’a appris à ses dépens une startup qui a vu une simple erreur de ChatGPT lui coûter plus de 10 000 dollars. La startup en question avait activé la monétisation de son service, mais a rapidement été confrontée à un problème majeur : les utilisateurs ne pouvaient pas s’abonner, entraînant de nombreuses plaintes et la perte potentielle de clients. L’erreur a été retracée jusqu’à une seule ligne de code qui provoquait des collisions d’ID uniques pendant le processus d’abonnement.Une startup raconte ses débuts et les défis qu'elle a dû relever lorsqu'elle s'est tournée pour la première fois vers la monétisation. Malgré ses faibles attentes, l'entreprise a été agréablement surprise d'avoir son premier client dans l'heure qui a suivi son lancement. Cependant, elle s'est rapidement trouvée confrontée à un problème majeur : elle a commencé à recevoir de nombreuses plaintes d'utilisateurs qui ne parvenaient pas à s'abonner. Malgré leurs efforts, ils n'ont pas réussi à reproduire le problème, qui semblait se produire principalement en dehors de leurs heures de travail.
Le problème, qualifié « d'hallucination à 10 000 dollars », a finalement été retracé jusqu'à une seule ligne de code qui provoquait des collisions d'identifiants uniques pendant le processus d'abonnement. Ce problème était caché en raison de la configuration de leur backend et a pris de l'ampleur lorsqu'ils ont cessé d'effectuer des modifications la nuit. Le problème a finalement été résolu et, malgré les difficultés et les ventes perdues, l'équipe considère cette expérience comme une leçon précieuse tirée de son parcours de startup.
Ce qui suit est un extrait de leur billet.
Nous avons commencé à utiliser la monétisation pour notre startup en mai dernier. Nous avions peu d'attentes, mais nous avons été agréablement surpris lorsque nous avons eu notre premier client dans l'heure qui a suivi le lancement. Ce fut un moment magique. Nous les avons remerciés, nous avons porté un toast et, comme nous venions de passer deux nuits blanches à tout préparer, nous nous sommes rapidement endormis.
Nous nous sommes réveillés ce matin-là avec plus de 40 notifications gmail de plaintes d'utilisateurs. Tout semblait s'être enflammé pendant la nuit. Aucun de ces utilisateurs ne pouvait s'abonner. Nous ne savions pas pourquoi.
Notre chemin vers la monétisation
Pour la petite histoire, le mois de mai a marqué le début du lot S23 YC et nous n'étions pas sûrs de la direction optimale à prendre après le lancement. Dalton, notre partenaire du groupe JCT, nous a conseillé d'utiliser les abonnés payants comme boussole et nous a dit de doubler le prix mensuel que nous avions déjà en tête. Finalement (et à contrecœur), nous sommes arrivés à 40 dollars par mois. Après la réunion, nous nous sommes immédiatement mis au travail pour mettre en place la monétisation. Notre projet était à l'origine une pile complète de NextJS mais nous voulions d'abord tout migrer vers Python/FastAPI. Nous l'avons fait (avec l'aide de ChatGPT), nous avons intégré Stripe... puis nous avons enchaîné avec cinq jours de sommeil, le moins que nous ayons eu de tout le mois. (Oui, cinq jours, c'est long pour trouver ce bug).
Pendant ces cinq jours, nous avons commencé à redouter de nous réveiller, sachant que nous allions être accueillis par 30/40/50 courriels de plaintes. Je me demande toujours combien de clients nous avons perdus à cause de cela. 50 courriels par jour x 5 jours x 40 par mois = 10 000 ventes perdues par mois - et ce, uniquement de la part de personnes qui se sentaient suffisamment concernées pour se plaindre. Nous répondions à ces courriels tous les jours comme des horloges. Nous ouvrions un nouveau compte, nous vérifiions que les abonnements ne posaient aucun problème, puis nous continuions à travailler dans la confusion. Rien de ce que nous faisions ne permettait de reproduire le problème et, plus étrange encore, nous ne recevions pratiquement aucune plainte pendant nos heures de travail.
L'hallucination à 10 000 dollars
Le voyage entre l'identification du problème et sa résolution effective a semblé prendre des mois. Cinq jours plus tard, d'innombrables courriels, des centaines de journaux sentry, de longs messages discord avec les ingénieurs de Stripe, et des heures et des heures à regarder cinq fichiers clés plus tard, nous l'avons trouvé 🎉. Essayez de voir si vous pouvez le repérer vous-même avant de lire la suite.
Si vous ne l'avez pas encore trouvé, le coupable était une simple ligne d'apparence innocente. Une ligne qui a été le fléau de notre existence pendant cette semaine. Une ligne qui nous a littéralement coûté 10 000 dollars. La redoutable ligne 56.
Dans le cadre de la migration de notre backend, nous traduisions les modèles de base de données de Prisma/Typescript en Python/SQLAlchemy. C'était vraiment fastidieux. Nous avons trouvé que ChatGPT faisait un travail assez exceptionnel pour cette traduction et nous l'avons donc utilisé pour la quasi-totalité de la migration. Nous avons copié-collé le code qu'il générait, nous avons vu que tout fonctionnait bien, nous l'avons essayé en production, nous avons vu que cela fonctionnait aussi, et nous avons poursuivi notre chemin.
Cependant, à ce stade, nous utilisions toujours notre API Next pour toutes les insertions dans la base de données. Python ne faisait que lire dans la base de données. La première fois que nous avons commencé à insérer des enregistrements dans la base de données en Python, c'est lorsque nous avons mis en place les abonnements. Bien que nous ayons créé à la main de nouveaux modèles SQLAlchemy pendant le processus, nous avons fini par copier le même format que ChatGPT a écrit pour nos modèles existants. Ce que nous n'avons pas remarqué, c'est que nous copiions le même problème avec la façon dont nous générions les identifiants dans tous nos modèles.
Correction de bogues
Le problème avec la ligne 56 était que nous ne faisions que passer une chaîne d'ID codée en dur au lieu d'une fonction ou d'une lambda pour générer des UUID pour nos enregistrements. Cela signifiait que pour toute instance donnée de notre backend, une fois qu'un nouvel utilisateur s'était abonné et avait utilisé cet identifiant, aucun autre utilisateur ne pouvait effectuer l'abonnement à nouveau car il en résultait une collision d'identifiant unique. Ce problème est devenu très bien caché en raison de la configuration de notre backend. Nous avions huit tâches ECS sur AWS, toutes exécutant cinq instances de notre backend (c'est exagéré, oui nous savons, mais pour être juste, nous avions des crédits AWS). Cela signifiait que chaque utilisateur disposait d'un pool de potentiellement 40 identifiants uniques sur lesquels il pouvait tomber.
Pendant la journée de travail, tout allait bien. Nous nous engagions probablement 10 à 20 fois par jour (directement sur le serveur principal bien sûr), ce qui entraînait de nouveaux déploiements de backend, nous donnant ainsi 40 nouveaux identifiants que les clients pouvaient potentiellement utiliser. Cependant, la nuit, lorsque nous avons finalement arrêté de faire des commits (quelle paresse de notre part, n'est-ce pas ?), l'ID unique de chaque serveur était capturé et provoquait des collisions d'ID dans tous les nouveaux abonnements. Les utilisateurs commençaient avec 40 serveurs possibles qui leur permettaient de s'abonner, et finissaient rapidement avec presque zéro au fur et à mesure que la nuit avançait. Résoudre enfin ce problème a été comme un poids enlevé de nos épaules. Adam a rapidement mis en place le correctif après avoir découvert ce problème et, pour la première fois de la semaine, nous avons pu nous reposer sur nos lauriers (enfin, pas vraiment, car nous avions encore dix autres incendies, mais ces histoires feront l'objet d'un autre article).
Malgré les avancées de l'IA, la vigilance humaine reste indispensable
L’erreur de ChatGPT qui a coûté 10 000 dollars à cette startup est un rappel que, malgré les avancées de l’IA, la vigilance humaine reste indispensable. Les outils d’IA sont puissants, mais ils ne remplacent pas le jugement critique et l’expertise des développeurs. En fin de compte, c’est la responsabilité des équipes humaines de s’assurer que la technologie qu’elles utilisent est sûre et fiable.
D'ailleurs, l'erreur ne saurait être imputable entièrement à ChatGPT : les développeurs auraient du prendre la peine d'analyser le code au lieu de se limiter à quelques tests avant la copie. Ils semblent le reconnaitre lorsqu'ils déclarent :
« Je voudrais commencer par dire que les pratiques en question sont très mauvaises et embarrassantes (et nous avons depuis ajouté des tests unitaires et d'intégration robustes ainsi que des alertes et des enregistrements), qu'elles auraient pu et dû être évitées, qu'il s'agissait d'erreurs humaines au-delà de tout, et qu'elles sont très évidentes avec le recul.
« Cela s'est passé à une autre époque, avec d'importantes contraintes de temps, aux tout premiers stades (premières semaines) de la création d'une entreprise. Je partage surtout cette histoire comme une anecdote amusante avec des circonstances uniques entourant la reproductibilité des bogues en prod (encore une fois à cause de notre propre stupidité) ».
Quoi qu'il en soit, tout est bien qui finit bien : « Rétrospectivement, aussi pénibles qu'aient été ces cinq jours, c'est l'un de ces moments de la vie d'une startup que nous n'oublierons jamais. Comme toutes les startups, nous avons fait une tonne d'erreurs tout au long de notre parcours, celle-ci étant peut-être la pire. J'évoquerai peut-être les autres plus tard. Nous sommes simplement heureux de pouvoir regarder ces jours-là en arrière et d'en rire. Oui, nous aurions dû faire plus de tests. Oui, nous n'aurions pas dû copier-coller du code. Oui, nous n'aurions pas dû passer directement à l'application principale. Quoi qu'il en soit, je ne regrette pas cette expérience ».
Source : rapport de la startup
Et vous ?
Quelle est votre opinion sur la fiabilité de l’intelligence artificielle dans les processus critiques d’entreprise ? Avez-vous des expériences personnelles où l’IA a joué un rôle crucial, positivement ou négativement, dans votre travail ? Comment pensez-vous que les entreprises peuvent équilibrer l’innovation technologique avec les risques potentiels associés à l’automatisation ? Selon vous, quelles mesures de sécurité devraient être mises en place lors de l’intégration de solutions d’IA dans les systèmes d’entreprise ? Pensez-vous que l’erreur mentionnée est un cas isolé ou révélateur d’un problème plus large dans l’industrie de l’IA ? Quelles stratégies votre entreprise a-t-elle adoptées pour prévenir les erreurs coûteuses liées à l’IA ? En tant que développeur ou utilisateur d’IA, comment assurez-vous la qualité et la précision du code généré par l’IA ? Quel rôle les tests et la validation jouent-ils dans votre utilisation de l’IA, et comment ces processus pourraient-ils être améliorés ? 
Envoyé par totozor
