Un auteur de Habr liste cinq décisions que l'ingénieur doit prendre avant le code généré par l'IA

L'un des bugs les plus désagréables de la logique de paiement paraît anodin : vérifier que l'opération est au statut PENDING, la passer à SUCCESS et créditer le solde. Si deux webhooks arrivent en même temps, tous deux voient PENDING, tous deux passent la vérification, et l'utilisateur reçoit l'argent deux fois. L'auteur d'un récent article sur Habr a trouvé une telle erreur dans sa propre place de marché. Il avait écrit le code lui-même, sans IA.

Cet exemple lui sert à poser la question centrale : si un agent implémente aujourd'hui ce type de gestionnaire en quelques minutes, qui fixe les contraintes absentes de la description fonctionnelle ? L'auteur examine ensuite cinq situations issues d'une place de marché et d'une plateforme multimarque, puis conclut par une checklist de 12 questions à passer en revue avant de générer du code.

Où la spécification reste muette

L'agent exécute bien ce qui est décrit. La phrase « en cas de webhook réussi, créditer le solde » est formellement respectée, que l'implémentation soit correcte ou vulnérable. La différence n'apparaît que sous charge parallèle, et les tests mono-thread ne la révèlent pas.

Ce n'est pas une propriété des modèles de langage, mais de toute énoncé de tâche qui omet les exigences non fonctionnelles. Un humain comble généralement ce vide par l'expérience et le souvenir des incidents passés. L'agent n'a aucune source pour ce contexte si on ne le lui fournit pas explicitement.

L'auteur isole cinq domaines où ces décisions se prennent en amont :

• idempotence des paiements : ce qui compte comme une requête répétée et où cela est garanti ;
• migrations de données : l'ordre des changements et le comportement du système dans les états intermédiaires ;
• livraison de messages entre instances d'un service : ce qui se passe si le destinataire n'est pas le bon ou est indisponible ;
• intégrations de fournisseurs : comment le système se comporte en cas de répétitions, de retards et de réponses non standard ;
• architecture des marques : ce qui est commun à toutes les marques de la plateforme et ce qui se configure séparément.

L'auteur donne la liste complète des 12 questions dans l'article original. Une réserve s'impose ici : l'annonce ne détaille pas les solutions retenues. Ce qui suit décrit donc la façon dont l'industrie règle habituellement ces problèmes, et non les conclusions de l'auteur.

Comment on résout généralement ce problème

Pour l'histoire des webhooks, l'arsenal habituel est connu. Une clé unique d'événement ou une clé d'idempotence de requête. Une mise à jour conditionnelle atomique du type « passer à SUCCESS uniquement si le statut est encore PENDING », avec vérification du nombre de lignes affectées. Un verrouillage de l'enregistrement pour la durée de la transaction. Chacune de ces mesures transforme « vérifier, puis écrire » en une seule opération indivisible.

La logique est similaire pour les migrations et les messages. Côté migrations, il faut des changements de schéma qui fonctionnent tant que l'ancienne et la nouvelle version du service coexistent. Côté messages, il faut une livraison dont on a précisé d'avance si les pertes et les doublons sont acceptables. Ces décisions structurent le code : les prendre après la génération coûte cher, car il faudra réécrire plutôt que compléter.

Comment l'appliquer en pratique

Si vous confiez une tâche à un agent, mieux vaut y joindre un court bloc de contraintes. Qu'est-ce qui doit rester vrai en cas d'appel répété ? En cas de deux appels parallèles ? En cas de défaillance partielle d'un fournisseur externe ? Lors du déploiement d'une nouvelle version à côté de l'ancienne ?

Il est également utile de demander à l'agent non seulement d'écrire le code, mais aussi de lister les hypothèses qu'il a faites sur la concurrence et l'ordre des événements. L'écart entre ses hypothèses et les vôtres est le moyen le plus rapide de repérer la faille dans l'énoncé de la tâche.

Reste enfin la question des tests. Pour les chemins de paiement, il faut au moins un test avec des requêtes simultanées. Sinon, la vérification de la correction reste au niveau du « ça a l'air juste ». C'est exactement l'allure qu'avait le gestionnaire dans l'histoire de l'auteur : la logique se lisait comme correcte et ne cassait qu'en cas de course critique.

Les conclusions de l'article valent aussi pour le code écrit par un humain. L'IA accélère l'implémentation, mais les décisions sur les invariants du système doivent toujours être prises avant elle, et c'est l'ingénieur qui les prend.