Google dévoile Auto-Diagnose, un système d'IA qui trouve la cause des échecs de tests d'intégration

Google a présenté Auto-Diagnose, un système interne reposant sur un LLM qui analyse les logs des tests d'intégration en échec, extrait lui-même les lignes clés et publie un diagnostic directement dans la code review. Pour les grandes équipes d'ingénierie, c'est une tentative de supprimer l'un des coûts cachés les plus lourds du développement : les heures, parfois les jours, passées à chercher à la main la cause d'un échec parmi des dizaines de fichiers de logs.

Le problème est mesurable chez Google. Dans une enquête interne auprès de 6059 développeurs, le diagnostic des échecs de tests d'intégration figurait dans le top 5 des plaintes les plus fréquentes sur les outils d'ingénierie. Une enquête complémentaire auprès de 116 ingénieurs a montré que 38,4 % de ces échecs prennent plus d'une heure à résoudre, et 8,9 % plus d'une journée. Pour les tests unitaires, ces chiffres étaient respectivement de 2,7 % et 0 %.

La raison est simple : un test d'intégration n'échoue presque jamais à un seul endroit évident. Le cas typique comprend un test driver distinct, un ensemble de services au sein du system under test, des logs dispersés entre différents composants et une masse d'avertissements et d'erreurs sans rapport avec la cause racine. Dans l'étude de Google, le test en échec médian comptait 16 fichiers de logs et 2801 lignes de logs.

Auto-Diagnose s'insère dans le flux de développement existant. Quand un test d'intégration échoue, le système reçoit automatiquement l'événement, collecte les logs du test driver et des composants du SUT de niveau INFO et supérieur, les fusionne en un flux unique et les trie par date. Il envoie ensuite le tout, avec les métadonnées des composants, à Gemini 2.5 Flash.

Le modèle fonctionne sans fine-tuning sur des logs propres à Google : le pari ne repose pas sur le fine-tuning, mais sur un prompt strict et l'intégration au processus. Le prompt oblige le modèle à procéder par étapes : trouver les sections de logs, identifier le composant où l'échec s'est produit, vérifier le contexte, et seulement ensuite formuler une conclusion.

Le point clé est l'interdiction de deviner. Si les logs ne contiennent aucune ligne du composant précis qui n'a pas démarré ou n'est pas devenu healthy, le modèle ne doit pas extrapoler, mais répondre franchement que les données sont insuffisantes. La réponse est ensuite mise au format standard et publiée dans Critique, le système interne de code review de Google, où le développeur voit immédiatement la conclusion, les étapes de l'enquête et les lignes de logs les plus pertinentes.

Côté chiffres, le système ressemble moins à un prototype de laboratoire qu'à un outil interne réellement éprouvé. Lors d'une vérification manuelle sur 71 échecs réels issus de 39 équipes, Auto-Diagnose a correctement identifié la cause racine dans 64 cas, soit une précision de 90,14 %. Google l'a ensuite déployé sur tous les échecs d'intégration liés aux changements de code dans l'ensemble de l'entreprise, à partir de mai 2025. Sur cette période, le système a traité 52 635 tests uniques, 224 782 exécutions, 91 130 changements de code et 22 962 auteurs.

Le délai médian de publication du diagnostic dans la code review a été de 56 secondes, et le 90e percentile de 346 secondes : le résultat apparaît donc généralement avant que l'ingénieur ne soit passé pour de bon à une autre tâche. En moyenne, une exécution consomme 110 617 tokens en entrée et en génère 5962 en sortie.

Les retours sont eux aussi plutôt bons : sur 517 avis émis par 437 développeurs, la part de mentions Not helpful était de 5,8 %, sous le seuil interne de Google de 10 % pour ce type d'outils, et en matière d'utilité, Auto-Diagnose s'est classé 14e sur 370 systèmes publiant des findings dans Critique.

Il y a aussi un bénéfice secondaire important. Sept erreurs de l'évaluation manuelle se sont avérées non pas des échecs du modèle en tant que tel, mais des problèmes d'infrastructure de logging : dans certains cas, les logs du test driver n'étaient pas conservés après un crash ; dans d'autres, ceux du composant défaillant lui-même. Des réponses similaires du type « il faut plus de données » ont ensuite permis de repérer environ 20 autres problèmes d'infrastructure.

L'intérêt principal d'Auto-Diagnose ne tient donc pas seulement à l'accélération de l'analyse des échecs de tests par Google. L'entreprise illustre un usage plus pragmatique des LLM dans le développement : ne pas demander au modèle de corriger du code à l'aveugle, mais l'intégrer à un goulot d'étranglement du processus, lui imposer des règles strictes contre les conjectures et renvoyer le résultat là où l'ingénieur travaille déjà. Pour les grandes équipes, c'est peut-être un scénario plus précieux qu'un énième « assistant de code IA », car il réduit le temps nécessaire pour comprendre la cause d'un échec, et c'est le plus souvent ce qui retarde une release.