Ce que cinquante ans de recherche apprennent pour les agents¶
Ce chapitre condense la partie en leçons pour le contrôle qualité du développement par IA. Chaque leçon renvoie au chapitre qui la justifie dans cette partie, et au chapitre des parties IA où elle s'applique.
Sept leçons¶
1. Aucun contrôle ne suffit seul¶
Les inspections trouvent au mieux deux tiers des défauts avant test, les tests de 35 à 55 % selon leur type (ordres de grandeur de Capers Jones), trois analyseurs statiques combinés environ 4,5 % des bugs réels, et les techniques trouvent des défauts différents (Myers, Basili et Selby). La qualité vient de l'empilement de contrôles complémentaires (Inspection et revue, Tests).
Pour un orchestrateur : un plan de contrôle qui repose sur « les tests passent » seul est un plan à un étage (Plan de contrôle type).
2. Un contrôle se juge à son taux de faux positifs¶
Google n'accepte pas plus de 10 % de faux positifs effectifs pour un analyseur en revue, et a fait passer l'utilité de ses mutants de 15 % à 89 % uniquement en filtrant ce qu'il montrait (Analyse statique, Tests).
Pour un orchestrateur : c'est le critère qui manque aux relecteurs IA, dont 60 à 70 % des commentaires ne sont pas résolus (L'IA comme contrôleur). Mesurer le taux de faux positifs effectif de chaque contrôle automatique, et désactiver ceux qui dépassent un seuil.
3. Le moment du contrôle compte plus que sa puissance¶
Le même analyseur passe de presque 0 % à plus de 70 % de corrections chez Facebook quand il signale au moment du diff plutôt qu'en lot (Analyse statique).
Pour un orchestrateur : renvoyer les résultats des contrôles à l'agent pendant le run — c'est aussi la condition sous laquelle les modèles se corrigent réellement (Agents autonomes).
4. La revue humaine trouve peu de bugs, et de moins en moins quand elle grossit¶
La revue moderne produit surtout des remarques de maintenabilité, et sa détection baisse avec la taille, la vitesse et la méconnaissance du code (Inspection et revue, Facteurs humains).
Pour un orchestrateur : ne pas présenter la revue humaine comme le filet de sécurité contre les bugs. La réserver aux zones à risque et au propriétaire du code, limiter la taille des PR, et compter sur les contrôles mécaniques pour les défauts fonctionnels (Échantillonnage).
5. La couverture est une mauvaise cible, et toute cible est manipulée¶
La couverture ne prédit que faiblement l'efficacité des tests, et un objectif de couverture devient un plafond (Tests) ; DORA, SPACE et Google répètent qu'une mesure transformée en objectif se dégrade (Normes et cadres).
Pour un orchestrateur : ne jamais donner à un agent une métrique de contrôle comme objectif ; utiliser la mutation plutôt que la couverture pour juger les tests qu'il écrit (Causes spéciales).
6. Les modèles prédictifs et les lignes de base ne se transportent pas¶
3,4 % seulement des prédictions de défauts croisées entre projets fonctionnent ; les mesures de processus prédisent mieux que les mesures de code (Défauts).
Pour un orchestrateur : recalculer les limites des cartes par dépôt, par type de tâche et par modèle ; surveiller les étiquettes de processus (volume, churn, nombre d'acteurs) autant que le code (Instrumenter la chaîne).
7. L'humain qui supervise une machine se fie trop à elle¶
Le biais d'automatisation touche les experts et ne se corrige pas par la formation (Facteurs humains) ; les développeurs assistés par IA sont plus confiants sans être plus justes (Productivité).
Pour un orchestrateur : mesurer la revue humaine comme un instrument (injection périodique de défauts connus), et construire la parade dans la structure plutôt que dans les consignes.
Ce que la recherche humaine ne couvre pas¶
Deux différences empêchent de transposer ces résultats tels quels :
- le producteur peut tromper le contrôle. Rien dans la littérature sur la revue humaine ne traite d'un auteur qui modifierait les tests pour passer la revue — c'est le cas des agents (Causes spéciales) ;
- les volumes changent d'échelle. Les seuils de taille et de rythme de revue ont été mesurés sur des flux humains de quelques modifications par jour et par développeur ; un orchestrateur en produit beaucoup plus, ce qui rend l'échantillonnage inévitable.
À retenir
La recherche sur le développement humain ne dit pas « relisez tout ». Elle dit : empilez des contrôles différents, jugez-les à leurs faux positifs, placez-les au moment du changement, gardez les revues petites et confiées à ceux qui connaissent le code, ne transformez jamais une mesure en cible, et ne faites pas confiance à la vigilance. Toutes ces règles s'appliquent aux agents ; deux d'entre elles — l'indépendance du contrôle et l'échantillonnage — deviennent plus importantes encore.