L'analyse statique en industrie¶

L'analyse statique — des outils qui examinent le code sans l'exécuter pour y repérer des défauts — est le contrôle automatique le plus ancien après la compilation. Son histoire industrielle, documentée en détail par Google et Facebook, contient la leçon la plus directement transposable aux contrôles d'un orchestrateur d'agents : un contrôle juste mais mal placé ne sert à rien.

Pourquoi les développeurs ne s'en servent pas¶

Johnson, Song, Murphy-Hill et Bowdidge (ICSE 2013, résumé) ont interrogé 20 développeurs. Tous jugeaient l'analyse statique utile ; tous citaient les mêmes obstacles : les faux positifs et la présentation des avertissements. Les auteurs appellent à des outils qui aident à corriger, pas seulement à signaler.

Google : le taux de faux positifs effectif¶

La règle des 10 %¶

Google a construit Tricorder, une plateforme qui intègre des dizaines d'analyseurs à la revue de code (Sadowski et al., ICSE 2015, PDF). Sa notion centrale est le taux de faux positifs effectif : la part des signalements sur lesquels le développeur choisit de ne rien faire, qu'ils soient techniquement justes ou non. Les règles :

en revue de code, un analyseur doit rester sous 10 % de faux positifs effectifs ;
à 10 % ou plus, il est mis à l'épreuve ; au-delà de 25 %, il peut être désactivé immédiatement (version de 2015) ; la version de 2018 parle de désactivation dès 10 % ;
les contrôles qui bloquent la compilation doivent avoir « essentiellement zéro » faux positif.

En janvier 2018, le système analysait environ 50 000 modifications par jour en revue, recevait plus de 5 000 clics « à corriger » et environ 250 « inutile » par jour (Sadowski et al., CACM 2018, PDF).

L'échec du tableau de bord¶

Le même article raconte trois tentatives ratées d'intégration de l'outil FindBugs. La première, en 2006, publiait chaque nuit un tableau de bord des problèmes de toute la base de code : il trouvait « des centaines de bugs » mais « était peu utilisé parce qu'il se trouvait hors du flux de travail habituel des développeurs ».

Facebook : de 0 % à 70 % sans changer d'analyseur¶

Distefano, Fähndrich, Logozzo et O'Hearn (CACM 2019, PDF) racontent l'expérience la plus frappante du domaine, avec l'analyseur Infer :

en mode lot (analyse complète périodique, problèmes assignés aux développeurs), « presque aucun » des 20 à 30 problèmes assignés n'a été traité ; le taux de correction était « proche de zéro » ;
en mode au diff (signalement dans la revue de la modification qui introduit le problème), le taux de correction a « bondi à plus de 70 % ». « Le même programme d'analyse, avec le même taux de faux positifs. »

C'est un récit d'expérience, pas une expérience contrôlée — mais il est cohérent avec l'échec du tableau de bord de Google.

La leçon transposable

Un contrôle est efficace quand il signale au moment et à l'endroit où la personne qui peut corriger est en train de travailler sur le code concerné. C'est le principe du jidoka : la machine s'arrête sur le défaut, pas dans un rapport du lendemain. Pour un orchestrateur, cela veut dire que les contrôles (analyse statique, détection de contournement, vérification des dépendances) doivent tourner pendant le run, et leur résultat être renvoyé à l'agent pour correction — ce que confirment, côté IA, le linter de SWE-agent et les 55 % de failles corrigées par Copilot Chat quand on lui fournit l'avertissement (Agents autonomes). Un tableau de bord de qualité consulté chaque semaine sera ignoré.

Ce que l'analyse statique ne voit pas¶

Habib et Pradel (ASE 2018, données de réplication) ont fait tourner trois analyseurs reconnus (SpotBugs, Error Prone, Infer) sur 594 bugs réels de projets Java. Ensemble, ils en trouvent 27, soit environ 4,5 % ; les outils sont largement complémentaires.

Limite importante

L'analyse statique attrape des classes de défauts (pointeur nul, ressource non fermée, motif dangereux), pas des erreurs de logique propres au problème. Elle est indispensable comme poka-yoke, et insuffisante comme contrôle de réception. Les hausses d'avertissements mesurées après adoption de l'IA (+30 % avec Cursor, voir Productivité) ne mesurent donc qu'une partie de la dégradation.

À retenir

Le critère d'utilité d'un contrôle automatique est son taux de faux positifs effectif : Google exige moins de 10 % en revue, et presque zéro pour un contrôle bloquant.
Le moment du signalement compte plus que l'analyseur : de presque 0 % à plus de 70 % de correction chez Facebook en passant du lot au diff.
Trois analyseurs combinés trouvent environ 4,5 % des bugs réels : l'analyse statique est un poka-yoke, pas une réception.