Retour au blog
IARetour d'expérienceDéveloppementDebugArchitecture

Quand un bug résiste aux agents IA

Retour d'expérience sur un problème d'intégration où fournir davantage de contexte n'a pas permis aux agents IA de converger vers la bonne solution.

5 août 20265 min read

Quand un bug résiste aux agents IA

Depuis plusieurs mois, les agents IA ont profondément changé ma manière de développer.

Ils accélèrent la production de code, proposent des pistes pertinentes et prennent en charge une partie importante du travail répétitif.

Mais il existe encore des situations où ils montrent leurs limites.

J'en ai récemment fait l'expérience.

Un bug qui semblait pourtant bien documenté

Je travaillais sur une application mêlant frontend, backend et plusieurs composants intermédiaires.

Le problème concernait un mécanisme de protection CSRF (qui empêche un site tiers d'agir à ton insu à ta place).

Comme souvent, mon premier réflexe a été de faire confiance à l'agent.

Via un environnement Docker, je lui ai fourni le code.

Puis le contexte.

Puis les journaux.

Puis les retours du navigateur : console, détails cookies et network, captures d'écran.

À chaque étape, l'agent proposait une nouvelle hypothèse, crédible. Mais aucune ne permettait de résoudre le problème.

Le piège du "toujours plus de contexte"

À chaque nouvelle information, l'agent formulait une hypothèse crédible.

Je lui demandais de l'implémenter.

Quelques instants plus tard, une nouvelle version du code était prête.

Les tests passaient.

J'échouais... avec succès.

Le problème, lui, n'avait pas bougé.

J'ajoutais alors davantage de contexte, ce qui produisait... une nouvelle hypothèse.

Avec le recul, j'ai réalisé que j'étais entré dans ce que j'appelle une spirale des hypothèses.

Les tokens (l'unité de facturation/consommation d'un agent IA) continuaient de s'accumuler, mais ce n'était que la conséquence. Le véritable problème était ailleurs : je produisais toujours plus d'hypothèses, sans produire de fait nouveau permettant de les départager.

Voilà le piège : plus de contexte donne l'impression d'avancer, sans faire avancer le diagnostic.

Revenir aux fondamentaux

À un moment, j'ai arrêté de demander une nouvelle correction.

J'ai ouvert le code.

J'ai placé des points d'arrêt (breakpoints).

J'ai suivi l'exécution pas à pas.

Je ne cherchais plus une solution.

Je cherchais à observer ce qui se passait réellement.

C'est cette démarche qui m'a permis d'identifier le point exact où le comportement attendu divergeait de la réalité.

Une fois ce point trouvé, je ne disposais pas encore de la solution.

En revanche, je savais enfin où le problème prenait naissance.

Pour illustrer ce propos

Imagine deux personnes cherchant une fuite d'eau dans un immeuble.

La première reste dans son bureau avec les plans du bâtiment.

Elle étudie les canalisations.

Elle formule des hypothèses.

"La fuite vient probablement de cette colonne."

"Ou peut-être de cette dérivation."

Pendant ce temps, la seconde descend simplement à la cave avec une lampe.

Quelques minutes plus tard, elle remonte avec une seule information :

"L'eau coule ici."

À cet instant, toutes les hypothèses changent.

Ce n'est pas parce qu'elle est plus intelligente.

C'est parce qu'elle possède un fait que l'autre n'avait pas.

C'est exactement ce qui s'est passé dans mon cas.

Tant que nous raisonnions à partir du contexte disponible, nous produisions des hypothèses.

Le premier breakpoint a apporté un fait nouveau.

À partir de ce moment-là, les bonnes hypothèses sont devenues évidentes.

Hypothèse vs observation

Le mode hypothèse

On possède des informations.

On essaie d'en déduire la cause.

Chaque nouvelle hypothèse est plus ou moins crédible.

C'est exactement ce que fait un LLM (un modèle de langage, le moteur derrière un agent IA).

Le mode observation

On ne cherche plus à deviner.

On cherche à mesurer.

On pose un breakpoint.

On capture une requête.

On observe un cookie.

On collecte un fait nouveau.

Et c'est ce fait qui permet enfin de départager les hypothèses.

Les limites des agents face au diagnostic systémique

Cette expérience ne remet pas en cause l'intérêt des agents IA.

Je continue à les utiliser quotidiennement.

En revanche, elle rappelle qu'ils rencontrent encore des difficultés lorsqu'un problème naît de l'interaction entre plusieurs couches techniques.

Frontend.

Backend.

Cookies.

Headers.

Middlewares.

Proxy.

Sécurité.

Aucune de ces briques n'était défaillante prise isolément.

C'est leur combinaison qui produisait le bug.

Or c'est précisément ce type de diagnostic systémique qui reste difficile à automatiser.

Une réflexion sur le coût réel

Cette expérience m'a également fait réfléchir au coût d'utilisation des agents.

Face à ce problème, mon réflexe a été d'enrichir progressivement le contexte fourni à l'agent.

J'ai partagé un environnement Docker.

Les journaux d'exécution.

Les informations réseau du navigateur.

Les cookies.

Les captures d'écran.

Chaque nouvel élément semblait pouvoir débloquer le diagnostic.

Pourtant, au-delà d'un certain seuil, cette stratégie produit parfois un rendement décroissant.

Les tokens continuent d'être consommés.

Les hypothèses continuent d'être générées.

Mais la probabilité de découvrir la véritable cause n'augmente plus au même rythme.

À l'échelle d'une équipe ou d'une entreprise, ce type de situation peut rapidement représenter un coût non négligeable.

Ce que j'en retiens

Cette expérience m'a rappelé une chose essentielle.

Les agents IA sont d'excellents partenaires de développement.

Ils accélèrent énormément le travail.

Mais lorsqu'un problème devient véritablement systémique, le développeur doit parfois changer de posture.

Il ne s'agit plus de demander une nouvelle hypothèse.

Il s'agit de produire de nouvelles observations.

Les agents IA raisonnent à partir des faits que nous leur fournissons. Ils ne peuvent pas observer à notre place ce qui n'a pas encore été mesuré.

Cette expérience ne m'a pas appris à moins faire confiance aux agents IA.

Elle m'a appris à reconnaître le moment où il faut arrêter de leur demander une nouvelle hypothèse... et commencer à produire une nouvelle observation.

En résumé

Cette expérience ne m'a pas appris à moins faire confiance aux agents IA.

Elle m'a appris à reconnaître le moment où il faut arrêter de leur demander une nouvelle hypothèse... et commencer à produire une nouvelle observation.

Parce qu'au fond, le problème n'était pas que l'agent codait mal.

Il implémentait parfaitement... de mauvaises hypothèses.