Tout d'abord, ils ont utilisé ChatGPT pour réduire les coûts. Ensuite, ils nous ont engagés pour nettoyer la dette technique de AI.

Philip Tihonovich

29 mai 2025 10 min de lecture

Vous seriez surpris de savoir combien d'entreprises le font aujourd'hui.

Comme l'indiquent les rapports émanant de l'ensemble de l'industrie, il existe aujourd'hui un secteur spécialisé en pleine expansion pour les ingénieurs qui se consacrent à la correction des erreurs de code générées par le AI.

Le modèle est devenu remarquablement cohérent. Les entreprises se tournent vers ChatGPT pour générer des scripts de migration, des intégrations ou des fonctionnalités complètes, dans l'espoir de gagner du temps et de réduire les coûts. Après tout, la technologie semble rapide et accessible.

Les systèmes tombent alors en panne.

Et ils nous appellent.

Ces derniers temps, nous recevons de plus en plus de demandes de ce type. Non pas pour livrer un nouveau produit, mais pour démêler le désordre laissé par quelqu'un qui a confié son code de production à un modèle de langage.

À ce stade, cela commence à ressembler à une industrie de niche à part entière. La correction des bogues générés par le AI est désormais un service facturable. Et dans certains cas, un service très coûteux.

Rapport 2024 de GitClear confirme ce que nous avons constaté chez nos clients : Les outils de codage AI accélèrent la livraison, mais alimentent également la duplication, réduisent la réutilisation et gonflent les coûts de maintenance à long terme.

Dans un cas, un client s'est adressé à nous après qu'une migration générée par AI ait entraîné la perte de données clients critiques. Nous avons passé 30 heures à récupérer ce qui a été perdu, à réécrire la logique à partir de zéro et à nettoyer le pipeline. Le plus ironique, c'est qu'il aurait été moins coûteux de demander à un développeur senior de l'écrire à l'ancienne.

Soyons clairs, nous ne sommes pas "contre AI". Nous l'utilisons également. Et elle est utile dans le bon contexte, avec les bons garde-fous. Mais ce qui me frustre dans la dépendance excessive à l'égard du AI et de ses implications généralisées - et probablement vous aussi - c'est la pensée magique. L'idée qu'un modèle linguistique peut remplacer un véritable travail d'ingénierie.

Ce n'est pas le cas. Et comme le dit l'adage, la preuve est dans le pudding. Lorsque les entreprises prétendent le contraire, elles finissent par payer quelqu'un comme nous pour faire le ménage.

Alors, à quoi ressemble l'un de ces travaux de nettoyage ? Voici ce que les AI-afficionados ne vous disent pas en termes de temps perdu et d'argent gaspillé.

A quoi ressemble une demande typique

Le message est généralement formulé comme suit :

"Hey, peux-tu jeter un coup d'œil à un microservice que nous avons construit ? Nous avons utilisé ChatGPT pour générer la première version. Nous l'avons poussée vers la phase d'essai, et maintenant notre file d'attente RabbitMQ est complètement inondée."

Cela commence toujours par de petites choses. Une tâche qui semblait trop ennuyeuse ou trop longue. Quelque chose comme l'analyse d'un fichier CSV, la réécriture d'une tâche cron ou le câblage d'un simple webhook. Ils la confient donc à un modèle de langage et espèrent que tout ira pour le mieux.

Mais voilà : les symptômes se manifestent beaucoup plus tard. Parfois des jours plus tard. Et lorsqu'ils apparaissent, il est rarement évident que la cause première est le code généré par AI. On a juste l'impression que... quelque chose ne va pas.

"On ne peut pas confier la réflexion architecturale à un modèle de langage. AI peut accélérer les choses, mais il faut toujours des ingénieurs pour construire des systèmes qui ne s'effondrent pas sous la pression".

Dmitry Nazarevich

Directeur technique

Après une douzaine de ces cas, des schémas commencent à se dessiner :

Pas de tests. Pas du tout. Pas même une affirmation de bonjour au monde. Juste du code brut et spéculatif qui n'a jamais été exercé correctement.
Aucune conscience des limites du système. Nous avons vu des scripts ChatGPT qui interrogent trois microservices de manière synchrone, ignorent les délais d'attente et font exploser toute la chaîne d'appels à la première défaillance.
Utilisation abusive des transactions. Un client a utilisé le SQL généré par AI avec des transactions imbriquées dans un service Node.js utilisant Knex. Cela a fonctionné, jusqu'à ce que ce ne soit plus le cas, et que la moitié des écritures échouent silencieusement.
Des conditions de course subtiles. Particulièrement dans les codes multithreads ou asynchrones. Le genre de bogues qui n'apparaissent pas en développement mais qui détruisent la production à grande échelle.

Et bien sûr, lorsque tout s'effondre, le AI ne vous laisse pas un commentaire disant "Au fait, je devine ici".

C'est à vous de jouer.

Cas 1 : Le script de migration qui a discrètement abandonné les données des clients

Celle-ci émane d'une entreprise de fintech à croissance rapide.

Ils étaient en train de déployer une nouvelle version de leur modèle de données clients, en divisant un grand champ JSONB dans Postgres en plusieurs tables normalisées. Un travail plutôt standard. Mais avec des délais serrés et pas assez de mains, l'un des développeurs a décidé d'accélérer les choses en demandant à ChatGPT de générer un script de migration.

En apparence, tout se passait bien. Le script analysait le JSON, extrayait les informations de contact et les insérait dans un nouveau fichier contacts_utilisateur table.

Ils l'ont donc fait fonctionner.

Pas d'essai. Pas de sauvegarde. Directement dans la phase d'essai, qui, comme il s'avère, partageait des données avec la production par l'intermédiaire d'une réplique.

Quelques heures plus tard, le service clientèle a commencé à recevoir des courriels. Les utilisateurs ne recevaient pas de notifications de paiement. D'autres avaient des numéros de téléphone manquants dans leur profil. C'est alors qu'ils nous ont appelés.

Ce qui n'a pas fonctionné

Nous avons remonté le problème jusqu'au script. Il a effectué l'extraction de base, mais il a fait trois hypothèses fatales :

Il n'a pas géré NULL ou des clés manquantes dans la structure JSON.
Il a inséré des enregistrements partiels sans validation.
Il a utilisé SUR LE CONFLIT NE RIEN FAIREde sorte que les insertions qui échouent sont silencieusement ignorées.

Résultat: à propos 18% des données de contact a été perdue ou corrompue. Pas de journaux. Pas de messages d'erreur. Juste une perte de données silencieuse.

Ce qu'il a fallu faire pour réparer

Nous avons chargé une petite équipe de démêler l'écheveau. Voici ce que nous avons fait :

Diagnostic et réplication (4 heures) Nous avons recréé le script dans un environnement sandbox et l'avons exécuté sur un instantané de la base de données. C'est ainsi que nous avons confirmé le problème et cartographié exactement ce qui manquait.
Audit légal des données (8 heures) Nous avons comparé l'état de rupture avec les sauvegardes, identifié tous les enregistrements contenant des données manquantes ou partielles et les avons comparés aux journaux d'événements afin de déterminer les insertions qui ont échoué et les raisons de cet échec.
Réécrire la logique de migration (12 heures) Nous avons réécrit l'intégralité du script en Python, ajouté une logique de validation complète, construit un mécanisme de retour en arrière et l'avons intégré dans le pipeline CI du client. Cette fois, nous avons inclus des tests et un support pour les essais à blanc.
Récupération manuelle des données (6 heures)Certains enregistrements étaient irrécupérables à partir des sauvegardes. Nous avons extrait les champs manquants de systèmes externes (API de leur CRM et de leur fournisseur de messagerie) et restauré manuellement le reste.

Durée totale : 30 heures d'ingénierie

Deux ingénieurs, trois jours. Coût pour le client : environ $4,500 en frais de service.Mais ce sont les retombées pour les clients qui ont le plus pesé dans la balance. L'échec des notifications a entraîné des retards de paiement et des désabonnements. Le client nous a dit qu'il avait dépensé au moins $10,000 sur les tickets d'assistance, les compensations SLA et les crédits de bonne volonté pour ce seul script raté.Le plus ironique, c'est qu'un développeur chevronné aurait pu écrire la bonne migration en quatre heures environ. Mais la promesse d'une vitesse de AI a fini par leur coûter deux semaines de nettoyage et d'atteinte à leur réputation.

Nous réparons ce que ChatGPT a cassé - et construisons ce qu'il n'a pas pu faire.

Cas 2 : Le client API qui a ignoré les limites de taux et a interrompu la production

Celle-ci provient d'une startup de technologie juridique qui construit une plateforme de gestion de documents pour les cabinets d'avocats. L'une de leurs principales fonctionnalités était l'intégration avec un service gouvernemental de notification électronique - une API REST tierce avec OAuth 2.0 et une limitation stricte du débit : 50 requêtes par minute, sans exception.

Au lieu de confier l'intégration à un développeur backend expérimenté, un membre de l'équipe a décidé d'en faire un "prototype" en utilisant ChatGPT. Ils ont ajouté la spécification OpenAPI, demandé un client Python, et ont obtenu un script d'apparence propre avec demandesLa logique de réessai utilisant ténacitéet l'actualisation du jeton.

Il avait l'air solide sur le papier. Ils l'ont donc expédié.

Ce qui n'a pas fonctionné

Au début, tout semblait aller bien. Le client traitait correctement les demandes individuelles, réussissait l'authentification et réessayait même en cas d'échec. Mais lors d'une utilisation réelle, en particulier en cas de charge, la plateforme a commencé à se comporter de manière imprévisible.

Voici ce qui s'est passé :

Aucun respect des limites tarifaires. Le code généré n'a pas lu ou interprété X-RateLimit-Remaining ou Réessayer après . Il a continué à envoyer des requêtes à l'aveuglette. Il a simplement continué à envoyer des requêtes à l'aveuglette.
Les réessais ont aggravé la situation. Lorsque les erreurs 429 ont commencé à revenir, le décorateur de ténacité les a retentées automatiquement. Pas de gigue. Pas de file d'attente. Juste un flot de demandes de suivi.
Le fournisseur d'API a temporairement bloqué leur IP. Pendant 3 heures, personne sur la plateforme n'a pu synchroniser les documents. Pas de journaux, pas d'alertes. Juste un échec silencieux.

Il ne s'agissait pas d'un simple correctif. Il s'agissait d'une mauvaise compréhension du comportement des systèmes de production. Et c'est un excellent exemple de ce que les LLM ne savent pas ; non pas parce qu'ils sont cassés, mais parce qu'ils n'ont pas conscience de l'exécution.

Arrêtez de patcher le code généré par AI dans prod - apportez-nous avant qu'il ne se casse.

Comment nous l'avons corrigé

Tracer et isoler la défaillance (6 heures) Nous avons ajouté un logiciel intermédiaire pour inspecter le trafic sortant et confirmé l'afflux de demandes lors des pics d'utilisation. Nous avons également recréé la défaillance en phase d'essai afin de comprendre pleinement le modèle de déclenchement.
Reconstruction du client API (10 heures) Nous avons réécrit le client en utilisant httpx.AsyncClienta mis en œuvre un accélérateur basé sur des sémaphores, a ajouté un ralentissement exponentiel avec une gigue, et a correctement traité les problèmes liés aux Réessayer après et les en-têtes de limitation de débit.
Test de stress et validation (6 heures) Nous avons simulé une utilisation réelle avec des milliers de requêtes simultanées à l'aide de Locust, testé l'étranglement du débit dans différents scénarios de rafales et confirmé qu'il n'y avait pas de 429s sous une charge soutenue.
Ajouter la surveillance et l'alerte (4 heures) Nous avons mis en place des mesures Prometheus personnalisées pour suivre l'utilisation de l'API par minute, et nous avons ajouté des alertes pour informer l'équipe lorsqu'elle s'approchait des seuils de taux.

Durée totale : 26 heures

Deux ingénieurs, répartis sur deux jours et demi. Coût pour le client : environ $3,900.

Le plus gros problème est que leur plus gros client - un cabinet d'avocats dont les dossiers sont sensibles au temps - a manqué deux fenêtres de soumission au tribunal à cause de la panne. Le client a dû limiter les dégâts et offrir une réduction pour conserver son compte.

Tout cela parce qu'un modèle de langage ne comprenait pas la différence entre "code de travail" et "code prêt pour la production". Et c'est ainsi qu'une nouvelle couche de dette technique AI a été discrètement ajoutée à la pile.

Pourquoi cela continue-t-il à se produire ?

Ce qui est effrayant, ce n'est pas que ces choses tournent mal. C'est à quel point tout cela devient prévisible.Chacun de ces incidents suit le même schéma. Un développeur demande à ChatGPT un extrait de code. Il obtient quelque chose qui fonctionne juste assez bien pour ne pas provoquer d'erreurs. Il l'intègre dans le système, le nettoie peut-être un peu et l'expédie, en partant du principe que s'il se compile et fonctionne, c'est qu'il est sûr.Mais c'est là que le bât blesse : Les grands modèles de langage ne connaissent pas votre système. Ils ne savent pas comment vos services interagissent. Ils ne connaissent pas votre budget de latence, votre pipeline de déploiement, votre configuration d'observabilité ou vos modèles de trafic de production.Ils génèrent le code le plus probable en se basant sur les modèles de leurs données d'apprentissage. C'est tout. Il n'y a pas de prise de conscience. Aucune garantie. Aucune intuition pour la conception du système.Et le résultat en est souvent le reflet :

Code qui fonctionne une fois, mais qui échoue sous charge
Pas de programmation défensive, pas de sécurité intégrée
Mauvaise compréhension des contraintes du monde réel, telles que les limites de taux, les délais ou la cohérence éventuelle.
Absence totale de sens de l'intention architecturale

Le pire, c'est que le code semble correct. Il est syntaxiquement propre. Il passe les linters. Il pourrait même être couvert par un test de base. Mais il manque la seule chose qui compte vraiment : le contexte.

C'est pourquoi ces bogues n'apparaissent pas immédiatement. Ils attendent les déploiements du vendredi soir, les fenêtres à fort trafic, les rares cas de figure. C'est la nature même de la dette technique AI - elle est invisible jusqu'à ce qu'elle brise quelque chose de critique.

Quand AI est utile

Comme nous l'avons mentionné précédemment, nous utilisons également AI. Pratiquement tous les ingénieurs de notre équipe ont une configuration de type Copilot qui fonctionne localement. C'est rapide, utile et, honnêtement, c'est un excellent moyen d'éviter les parties ennuyeuses.Mais voici la différence : rien n'arrive dans la branche principale sans passer par un ingénieur senior, et dans la plupart des cas, par un pipeline CI qui sait ce qu'il faut chercher.Les LLM sont excellents pour :

un modèle d'échafaudage pour de nouveaux services ou points d'extrémité d'API,
générer une couverture de test pour la logique existante,
aider au remaniement répétitif de grandes bases de code,
traduire de simples scripts shell en modèles d'infrastructure en tant que code,
ou même en comparant des approches algorithmiques que nous connaissons déjà.

Ce qu'ils sont pas est la conception. Ou le contexte. Ou les valeurs par défaut sûres.

C'est pourquoi nous avons conçu nos flux de travail de manière à traiter les résultats du LLM comme des suggestions et non comme une source de vérité. Voici ce que cela donne en pratique :

Nous marquons tous les commits générés par AI afin qu'ils soient faciles à tracer et à examiner.
Nos éditeurs disposent d'invites en ligne, mais avec des crochets de pré-commission imposés qui bloquent tout ce qui n'est pas testé ou documenté.
Notre IC comprend des règles d'analyse statique qui signalent les schémas peu sûrs que nous avons déjà vus dans les LLM : des choses comme les tentatives non surveillées, les délais non couverts, l'analyse JSON naïve ou la manipulation SQL peu sûre.
Chaque demande d'extraction de code généré par le LLM fait l'objet d'un examen humain obligatoire, généralement par une personne expérimentée qui comprend la logique du domaine et la surface de risque.

Utilisé à bon escient, il permet de gagner du temps. Utilisé à l'aveuglette, c'est une bombe à retardement.

Ce que nous recommandons aux directeurs techniques

Nous ne sommes pas là pour vous dire d'interdire les outils AI. Ce projet a été abandonné.Mais donner à un modèle linguistique l'accès à la validation ? C'est s'attirer des ennuis.Voici ce que nous recommandons à la place :

1. Traiter les LLM comme des outils et non comme des ingénieurs

Laissez-les vous aider avec le code répétitif. Qu'ils proposent des solutions. Mais ne leur confiez pas les décisions critiques. Tout code généré par AI doit être revu par un ingénieur senior, sans exception.

2. Rendre traçable le code généré par le LLM

Qu'il s'agisse de balises de validation, de métadonnées ou de commentaires dans le code, indiquer clairement quelles pièces proviennent de AI. Cela facilite l'audit, le débogage et la compréhension du profil de risque par la suite.

3. Définir une politique de génération

Décidez en équipe où il est acceptable d'utiliser des LLM et où ce n'est pas le cas. Le modèle de base ? Bien sûr. Les flux d'authentification ? Peut-être. Les systèmes transactionnels ? Absolument pas sans examen. Rendre la politique explicite et font partie de vos normes d'ingénierie.

4. Ajouter une surveillance au niveau DevOps

Si vous laissez le code généré par AI toucher la production, vous devez supposer que quelque chose finira par se casser. Ajoutez des contrôles synthétiques. Contrôle des limites de vitesse. Suivi des dépendances. Rendre l'invisible visiblesurtout lorsque l'auteur original n'est pas humain.

5. Construire pour la recouvrabilité

Les plus grosses défaillances dues au AI que nous ayons vues ne provenaient pas d'un "mauvais" code. Elles provenaient d'erreurs silencieuses - données manquantes, files d'attente interrompues, tempêtes de tentatives - qui n'étaient pas détectées pendant des heures. Investissez dans l'observabilité, la logique de repli et les retours en arrière. Surtout si vous laissez ChatGPT écrire des migrations.

En bref, AI peut faire gagner du temps à votre équipe, mais il ne peut pas en assumer la responsabilité.

Il s'agit toujours d'un travail humain.

Dernières réflexions : AI ≠ ingénieurs logiciels

AI peut vous aider à aller plus vite. Mais il ne peut pas penser à votre place.Il ne comprend pas votre architecture. Il ne sait pas ce que signifie "fait" dans votre contexte. Et il ne se soucie absolument pas de savoir si votre pipeline de données se brise silencieusement un vendredi soir.C'est pourquoi, en tant que directeurs techniques, nous devons rester concentrés sur la résilience du système, et pas seulement sur la vitesse.Il est tentant de laisser AI s'occuper des parties ennuyeuses. Et c'est parfois une bonne chose. Mais tout raccourci s'accompagne d'un compromis. Lorsque le code généré par AI passe inaperçu, il devient souvent une dette technique de AI. Le genre de dette que vous ne voyez pas jusqu'à ce que votre équipe d'exploitation lutte contre les incendies dans la production.Si vous vous êtes déjà heurté à ce mur, vous n'êtes pas seul. Nous avons aidé des équipes à se remettre de tout, des migrations interrompues aux désastres des API. Nous ne nous contentons pas de remanier le code. Nous aidons à remanier la pensée qui le sous-tend.Parce qu'en fin de compte, c'est ce qui rend les systèmes fiables.

Philip Tikhanovich

Chef du département Python, Big Data, ML/DS/AI

Philip apporte une attention particulière à tout ce qui touche aux données et à AI. C'est lui qui pose les bonnes questions dès le début, qui définit une vision technique forte et qui s'assure que nous ne construisons pas simplement des systèmes intelligents, mais que nous construisons les bons, pour une valeur commerciale réelle.

Lire la suite

Table des matières

Contactez-nous

Reservez un appel ou remplissez le formulaire ci-dessous et nous vous contacterons dès que nous aurons traité votre demande.

Nom

Entreprise

Courriel :

Téléphone

Message

Envoyez-nous un message vocal

Joindre des documents

Charger fichier

Vous pouvez joindre un fichier d'une taille maximale de 2 Mo. Formats de fichiers valables : pdf, jpg, jpeg, png.

En cliquant sur Envoyer, vous consentez à ce qu'Innowise traite vos données personnelles conformément à notre politique de confidentialité. Politique de confidentialité pour vous fournir des informations pertinentes. En communiquant votre numéro de téléphone, vous acceptez que nous puissions vous contacter par le biais d'appels vocaux, de SMS et d'applications de messagerie. Les tarifs des appels, des messages et des données peuvent s'appliquer.

Vous pouvez également nous envoyer votre demande
à contact@innowise.com

Que se passe-t-il ensuite?

Une fois que nous aurons reçu et traité votre demande, nous vous contacterons pour détailler les besoins de votre projet et signer un accord de confidentialité. Projet et signer un accord de confidentialité.

Après avoir examiné vos souhaits, vos besoins et vos attentes, notre équipe élaborera une proposition de projet avec l'étendue des travaux, la taille de l'équipe, les délais et les coûts estimés. projet avec l'étendue des travaux, la taille de l'équipe, les délais et les coûts estimés.

Nous prendrons rendez-vous avec vous pour discuter de l'offre et régler les détails.

Enfin, nous signons un contrat et commençons immédiatement à travailler sur votre projet.

Tout d'abord, ils ont utilisé ChatGPT pour réduire les coûts. Ensuite, ils nous ont engagés pour nettoyer la dette technique de AI.

A quoi ressemble une demande typique

Cas 1 : Le script de migration qui a discrètement abandonné les données des clients

Ce qui n'a pas fonctionné

Ce qu'il a fallu faire pour réparer

Durée totale : 30 heures d'ingénierie

Nous réparons ce que ChatGPT a cassé - et construisons ce qu'il n'a pas pu faire.

Cas 2 : Le client API qui a ignoré les limites de taux et a interrompu la production

Ce qui n'a pas fonctionné

Arrêtez de patcher le code généré par AI dans prod - apportez-nous avant qu'il ne se casse.

Comment nous l'avons corrigé

Durée totale : 26 heures

Pourquoi cela continue-t-il à se produire ?

Quand AI est utile

Ce que nous recommandons aux directeurs techniques

1. Traiter les LLM comme des outils et non comme des ingénieurs

2. Rendre traçable le code généré par le LLM

3. Définir une politique de génération

4. Ajouter une surveillance au niveau DevOps

5. Construire pour la recouvrabilité

Dernières réflexions : AI ≠ ingénieurs logiciels

Lire la suite

Table des matières

Contactez-nous

Que se passe-t-il ensuite?

Contenu connexe

Vous avez besoin d'autres services?

Tout d'abord, ils ont utilisé ChatGPT pour réduire les coûts. Ensuite, ils nous ont engagés pour nettoyer la dette technique de AI.

A quoi ressemble une demande typique

Cas 1 : Le script de migration qui a discrètement abandonné les données des clients

Ce qui n'a pas fonctionné

Ce qu'il a fallu faire pour réparer

Durée totale : 30 heures d'ingénierie

Nous réparons ce que ChatGPT a cassé - et construisons ce qu'il n'a pas pu faire.

Cas 2 : Le client API qui a ignoré les limites de taux et a interrompu la production

Ce qui n'a pas fonctionné

Arrêtez de patcher le code généré par AI dans prod - apportez-nous avant qu'il ne se casse.

Comment nous l'avons corrigé

Durée totale : 26 heures

Pourquoi cela continue-t-il à se produire ?

Quand AI est utile

Ce que nous recommandons aux directeurs techniques

1. Traiter les LLM comme des outils et non comme des ingénieurs

2. Rendre traçable le code généré par le LLM

3. Définir une politique de génération

4. Ajouter une surveillance au niveau DevOps

5. Construire pour la recouvrabilité

Dernières réflexions : AI ≠ ingénieurs logiciels

Lire la suite

Table des matières

Contactez-nous

Que se passe-t-il ensuite?

Contenu connexe

Vous avez besoin d'autres services?

S'abonner à à notre bulletin d'information

S'abonner à
à notre bulletin d'information