Facteurs humains du contrôle¶
Tous les chapitres précédents supposent, à un moment, un humain qui relit, juge ou décide. Ce chapitre rassemble ce que la recherche sait des limites de cet humain : sa mémoire de travail, ses interruptions, son expérience, et sa tendance à faire confiance aux machines. C'est le chapitre le plus directement utile pour concevoir la revue humaine d'un orchestrateur d'agents.
La charge cognitive du relecteur¶
Taille de la modification et mémoire de travail¶
Baum, Schneider et Bacchelli (Empirical Software Engineering 24(4), 2019) ont fait relire à une cinquantaine de participants, en majorité des professionnels, des modifications contenant des défauts injectés. Deux résultats :
- l'efficacité de la revue est significativement plus grande pour les petites modifications ;
- la capacité de mémoire de travail du relecteur est modérément associée à la détection des défauts délocalisés — ceux qui demandent de relier des morceaux de code éloignés —, presque pas aux autres.
La seconde observation précise la première : une grosse modification est difficile parce qu'elle contient plus de défauts qui exigent de tenir plusieurs endroits en tête à la fois.
Les listes de contrôle aident peu¶
Gonçalves et al. (EMSE 2022, rapport enregistré à l'avance) ont comparé la revue libre, la revue avec liste de contrôle et la revue avec liste guidée. Ils ne trouvent pas de relation forte entre le guidage et la performance, et observent que les participants (surtout des novices) réussissaient mal dans l'ensemble.
L'expérience du relecteur¶
- Chez Microsoft, un relecteur qui découvre une zone de code écrit environ 33 % de commentaires utiles ; il atteint environ 67 % à la troisième revue de cette zone, puis la moyenne du projet (Czerwonka et al., 2015). Bosu, Greiler et Bird (2015) trouvent que la part de commentaires utiles d'un relecteur augmente fortement pendant sa première année, puis plafonne.
- Côté auteur, Mockus et Weiss (Bell Labs Technical Journal, 2000) trouvent sur le commutateur 5ESS que l'expérience du développeur et la diffusion de la modification (nombre de fichiers, modules, sous-systèmes touchés) prédisent le risque qu'une modification échoue ; plus d'expérience, moins de risque (effets chiffrés non vérifiés pour ce rapport).
Conséquence pour les PR d'agents
Un humain qui relit une PR d'agent sur une partie du code qu'il ne connaît pas est dans la situation du relecteur débutant de Microsoft : environ un tiers de commentaires utiles. Or c'est la situation la plus fréquente dans les études de PR d'agents, où plus des deux tiers des PR co-écrites par IA viennent de contributeurs qui ne sont pas propriétaires du code (PR d'agents). Le relecteur d'une PR d'agent devrait être, autant que possible, le propriétaire du code touché.
Les interruptions¶
Parnin et Rugaber (Software Quality Journal, 2011, PDF) ont analysé 10 000 sessions de programmation de 86 développeurs : dans seulement 10 % des sessions, l'activité de programmation reprend moins d'une minute après une interruption, et seulement 7 % des sessions commencent une modification sans naviguer d'abord dans le code pour retrouver le contexte. Ma et al. (ICSE 2024) trouvent sur 20 étudiants que les interruptions affectent significativement le temps passé en revue et en compréhension de code.
Le cadre DevEx (Normes et cadres) range précisément l'attente d'une approbation de revue parmi les boucles de retour qui cassent le flow — et note qu'une revue rapide peut tout de même être perturbante si elle interrompt régulièrement le relecteur.
Le piège d'un orchestrateur très productif
Un orchestrateur qui ouvre des dizaines de PR par jour transforme la revue en flux d'interruptions. Chaque PR exige de reconstruire un contexte (Parnin : rarement en moins d'une minute), sur un code souvent inconnu, avec une efficacité qui baisse avec la taille. La conséquence attendue, cohérente avec Faros AI (+91 % de temps de revue) et avec les taux de revue superficielle mesurés : une revue qui devient de pure forme. C'est un argument de plus pour l'échantillonnage plutôt que la revue exhaustive, et pour regrouper les revues en plages dédiées.
Le biais d'automatisation¶
La synthèse de référence est celle de Parasuraman et Manzey (Human Factors 52(3), 2010, texte), issue de la recherche en aviation, en médecine et en contrôle de processus. Elle distingue deux phénomènes liés :
- la complaisance envers l'automatisation : elle « survient dans des conditions de charge multitâche, quand des tâches manuelles entrent en concurrence avec la tâche automatisée » ; elle touche les novices comme les experts et « ne peut pas être surmontée par la simple pratique » ;
- le biais d'automatisation : il « survient chez les novices comme chez les experts, ne peut pas être prévenu par la formation ou les consignes, et peut affecter la prise de décision des individus comme des équipes ».
Le biais produit deux sortes d'erreurs :
| Erreur | Définition | Forme dans la revue de code |
|---|---|---|
| Omission | Ne pas voir ce que l'aide automatique n'a pas signalé | Le relecteur ne cherche plus ce que le relecteur IA ou la CI n'a pas marqué |
| Commission | Suivre une recommandation fausse de l'aide | Le relecteur applique une suggestion erronée du relecteur IA |
Limite importante pour les orchestrateurs
La condition de Parasuraman et Manzey — un humain chargé de plusieurs tâches pendant qu'un système automatique signale des problèmes — décrit exactement le relecteur d'un orchestrateur assisté par un relecteur IA. Et leur conclusion la plus gênante est que la formation et les consignes ne suffisent pas. La parade ne peut donc pas être « soyez vigilants » ; elle doit être structurelle : limiter la charge de revue (échantillonnage), placer certains contrôles avant que l'humain voie le verdict automatique, et mesurer la qualité de la revue humaine elle-même (par exemple en injectant périodiquement des défauts connus, comme on passe un étalon dans un instrument).
À retenir
- L'efficacité d'un relecteur baisse avec la taille de la modification et dépend de sa mémoire de travail pour les défauts délocalisés ; les listes de contrôle aident peu.
- Un relecteur qui découvre le code fait environ un tiers de commentaires utiles ; il lui faut plusieurs revues pour atteindre la moyenne.
- Les interruptions coûtent cher : la reprise prend rarement moins d'une minute.
- Le biais d'automatisation touche aussi les experts et ne se corrige pas par la formation : la parade est structurelle.