Pourquoi l'IA ne doit pas seulement nous apprendre à coder plus vite

L'IA est en train de bouleverser la manière dont les logiciels sont conçus. Génération de code, développement de fonctionnalités, revue des pull requests peuvent désormais être largement automatisés.

Dans cette course à la productivité, le véritable enjeu n’est peut-être plus de produire davantage de code, mais de mieux comprendre les problèmes que l’on cherche à résoudre.

Dans mon entreprise, nous utilisons massivement ces outils. Pourtant, une interrogation s'est imposée : ne serions-nous pas en train de focaliser nos efforts sur la partie la plus visible du travail d'ingénierie plutôt que sur la plus coûteuse ?

Lorsqu’un problème survient en production, l’écriture du correctif est rarement le facteur bloquant. Comprendre ce qui a cassé l'est.

Le mythe des 20 dernières minutes

Prenons un ratio classique du support technique : un ingénieur passe 70 minutes à comprendre l'origine d'une anomalie et 20 minutes à rédiger la solution. Si un assistant IA permet de doubler la vitesse de codage sur ces 20 dernières minutes, vous ne gagnez que 10 minutes sur un incident de 90 minutes. L'effort est louable, mais le gain marginal reste faible.

Ce constat nous a poussés à faire un pari différent : au lieu d'équiper nos développeurs uniquement d'outils de génération de code, nous avons conçu des agents d'IA dédiés à l'investigation automatisée.

De l'assistant de codage à l'agent "enquêteur"

Dans notre écosystème, une simple transaction implique ma plateforme, un prestataire de paiement, le système de caisse (POS) d'un restaurant, des configurations spécifiques et plusieurs services internes. Quand un pourboire disparaît, le champ des possibles est immense.

Au lieu d'offrir un chatbot générique aux ingénieurs, nous avons confié à un agent une tâche ciblée : partir du ticket de support, identifier la transaction, croiser les événements système, fouiller la base de connaissances et construire une chronologie des faits.

Résultat : des investigations qui exigeaient autrefois 90 minutes n’en prennent plus que 10. L'ingénieur ne gagne pas du temps parce que le code est rédigé plus vite, mais parce qu'il ne démarre plus son enquête d'une page blanche.

La pensée contradictoire pour éviter les faux diagnostics

Pour qu'un tel agent soit fiable, il a fallu résoudre un biais classique : s'arrêter à la première explication convaincante. Un bon enquêteur ne cherche pas seulement les preuves qui confirment son hypothèse ; il cherche l'élément susceptible de la réfuter. C'est pourquoi nous imposons à notre agent une seconde passe obligatoire : tester la première théorie en tentant activement de la déconstruire (vérification de l'historique des configurations, alignement des horodatages, détection d'événements contradictoires).

Grâce à cette étape, nous évitons les fausses pistes qui auraient conduit à incriminer nos propres services alors que le problème résidait dans une désynchronisation temporaire côté client.

Révéler les failles invisibles de nos systèmes

Cette approche a révélé un enseignement capital : un agent d'IA ne sait que ce qu'on lui rend visible. Là où un ingénieur humain compense intuitivement les angles morts (en sachant quel log est incomplet ou qui interroger sur Slack), l'agent bute dès qu'une donnée manque. Lorsque l'agent ne comprend pas un incident, la question à se poser n'est plus "pourquoi l'IA se trompe-t-elle ?", mais "quelle donnée manquait à nos systèmes ?".

En corrigeant ces manques (logs absents, identifiants mal alignés, documentation incomplète), nous améliorons l'agent, tout en rendant l'architecture plus claire pour les humains.

Le code n'est que le "dernier kilomètre"

Il est temps de changer de perspective. La génération de code ne représente que le "dernier kilomètre" de l'ingénierie logicielle. La vraie valeur ajoutée de l'IA se situe plus en amont : elle doit d'abord servir à comprendre les problèmes de production en automatisant le travail d'enquête, puis à analyser les besoins réels du produit avant même d'en spécifier la moindre ligne de code.

Que vous corrigiez une panne ou que vous conceviez un produit, la règle ne change pas : la qualité de la solution dépend d'abord de la finesse avec laquelle vous avez analysé le problème.