Votre message a été envoyé.
Nous traiterons votre demande et vous contacterons dès que possible.
Le formulaire a été soumis avec succès.
Vous trouverez de plus amples informations dans votre boîte aux lettres.
Sélection de la langue
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.
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é.
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."
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.
Après une douzaine de ces cas, des schémas commencent à se dessiner :
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.
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 user_contacts
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.
Nous avons remonté le problème jusqu'au script. Il a effectué l'extraction de base, mais il a fait trois hypothèses fatales :
NULL
ou des clés manquantes dans la structure JSON.ON CONFLICT DO NOTHING
, de 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.
Nous avons chargé une petite équipe de démêler l'écheveau. Voici ce que nous avons fait :
Deux ingénieurs, trois jours. Coût pour le client : environ $4,500 in service fees.
But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.
The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.
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 requests
, la logique de réessai utilisant tenacity
, et l'actualisation du jeton.
Il avait l'air solide sur le papier. Ils l'ont donc expédié.
Voici ce qui s'est passé :
X-RateLimit-Remaining
ou Retry-After
. Il a continué à envoyer des requêtes à l'aveuglette. Il a simplement continué à envoyer des requêtes à l'aveuglette.httpx.AsyncClient
, a 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 Retry-After
et les en-têtes de limitation de débit.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.
The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.
Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.
But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.
They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.
And the output often reflects that:
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.
As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.
But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.
LLMs are great at:
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 :
Utilisé à bon escient, il permet de gagner du temps. Utilisé à l'aveuglette, c'est une bombe à retardement.
We’re not here to tell you to ban AI tools. That ship has sailed.
But giving a language model commit access? That’s just asking for trouble.
Here’s what we recommend instead:
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.
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.
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.
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 visible, surtout lorsque l'auteur original n'est pas humain.
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.
AI can help you move faster. But it can’t think for you.
It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.
That’s why, as CTOs, we need to stay focused on system resilience, not just speed.
It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.
If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.
Because in the end, that’s what actually makes systems reliable.
Votre message a été envoyé.
Nous traiterons votre demande et vous contacterons dès que possible.
En vous inscrivant, vous acceptez notre Politique de confidentialitéy compris l'utilisation de cookies et le transfert de vos informations personnelles.