La (sur)-productivité à l'heure des agents

Les défis de la revue de code à l'heure agentique

Lors de ma dernière mission en tant que développeur, j'ai été exposé à une problématique que je ne pensais pas trouver un jour chez un gros client. A priori, on relierait plutôt les problèmes de sur-productivité aux startups (je n'ai jamais travaillé dans une startup, seulement en agence digitale mais je suppose que le phénomène du crunch est assez fréquent), ou au monde du jeu vidéo par exemple, mais certainement pas dans une équipe agile d'un grand groupe travaillant sur des applications métiers.

Et pourtant, ce fut le cas. L'équipe se révela particulièrement productive, livrait vite, massivement. On ne va pas se mentir ce fut grâce à l'adoption massive de l'IA, encouragée et poussée par notre client.

Je n'avais pas vu une telle vélocité depuis des années, mais plus nous trouvions nos marques et notre workflow avec les agents, plus nous rencontrions de nouveaux problèmes, liés à cette nouvelle vitesse.

Embouteillages

L'un d'entre eux concerne les revues de code. Plus fréquentes, plus nombreuses, elles s'accumulaient dangereusement. Le temps de la revue dépassait souvent le temps de développement. Oh, ce n'était pas nouveau, il y a souvent eu des soucis d'encombrement en phase de revue de code et de tests / validation, mais la taille du problème semblait s'aggraver dangereusement.

Pour ceux qui ne sont pas du métier, la revue de code est une pratique assez spécifique à l'informatique, où chaque livraison de notre travail est soumise à relecture d'un pair (au moins), puis discussion, demandes de corrections, puis enfin validation. C'est essentiel car ça garantit à la fois une sécurité sur ce qu'on produit et qu'on envoie en production, mais aussi l'information de ce qui a été produit, modifié, corrigé.

Avec l'IA, notre métier consiste de plus en plus à lire et contrôler le travail de nos collègues plutôt qu'à produire et écrire nous-mêmes.

Si c'est essentiel à la qualité et au travail en équipe, ce n'est pas non plus la partie de la plus "fun" du boulot, il faut bien le reconnaître. Parfois il y a des frictions, des difficultés de communication entre l'auteur et le relecteur. Souvent il n'y a pas de disponibilité et les revues de code attendent, au point mort, oubliées. Parfois elles sont horriblement longues et complexes, si bien qu'il faut bien du courage et du temps devant soi pour s'y mettre.

Vous voyez bien arriver le souci. Une équipe de 3 ou 4 développeurs va produire beaucoup plus vite grâce à l'IA, les revues de code vont s'ouvrir plus fréquemment, mais notre capacité de relecture, notre capacité de jugement et notre disponibilité, eux n'évoluent pas aussi vite.

Des pavés à relire

Une des nouveautés que j'ai vu apparaître dans des revues de code récentes, et que je mets sur le dos de l'IA est le dépassement de contexte et la taille des tickets. Puisqu'on peut coder plus vite, on peut également profiter de ce bonus de productivité pour en faire plus. Plus de tests (c'est bien), plus de détails (c'est bien aussi), mais aussi parfois plus de fonctionnalités, dont certaines non demandées. On en profite pour embarquer des choses non prévues car c'est pas cher.

Là évidemment, on va rentrer en négociation sur la revue de code. Si ce qui est livré ne correspond pas au cahier des charges et au ticket, si ça en fait beaucoup plus que prévu, ça va démarrer des débats et donc un délai supplémentaire dont on aurait franchement pu se passer.

L'IA est également assez peu économe dans la quantité de code qu'elle peut produire. Ça, ça se repère directement, et la revue de code va servir à pointer les redites, les choses à simplifier. Mais lorsqu'on se retrouve face à une revue de code de plus de 600 fichiers, notre vigilance va en prendre un coup, tout comme notre enthousiasme.

Certes, l'argument de la longueur ne doit pas être trop important. Un écrivain qui va soumettre un pavé de 900 pages à son éditeur, s'il reçoit comme première et seule remarque "c'est beaucoup trop long !", ce n'est pas entendable. C'est notre métier de lire du code, alors on va essayer d'expliquer pourquoi c'est trop long et proposer des axes d'optimisation.

Je n’ai jamais été un grand fan des revues de code. Elles apportent toujours un peu de friction. Parfois ça tourne au conflit, souvent sur des détails. Je ne suis pas du genre à me battre pour imposer à l’autre ma formulation. Je n’aime pas trop non plus batailler pendant des jours sur des détails. Je considère que nous sommes des professionnels, nous devons penser d’abord à nos clients et à nos employeurs, donc débattre pendant des heures sur un nom de fonction, on n’est pas loin de la faute professionnelle.

Des estimations biaisées

Autre conséquence, le référentiel de l'estimation des tâches évoluent. Si toute l'équipe voit sa productivité faire des bonds soudainement, c'est tout le système d'estimation qui explose. Nous sommes assez heureux d'être plus rapides et productifs, c'est vrai, mais cela doit être contrôlé, évalué. Les chefs de projets, PO, PM, et au delà les sponsors vont voir cette évolution, forcément.

Là où un développeur pouvait passer parfois un mois complet (2 sprints), voire plus sur une seule fonctionnalité, on peut voir dans certains cas que ce même genre de fonctionnalité aujourd'hui est faisable peut-être en 3 ou peut être 5 jours max et donc le gap total de productivité est quand même assez hallucinant, il faut reconnaître.

Il ne sera par la suite plus question de la remettre en cause, de revenir en arrière, de temporiser, souffler. Les conséquences pour l'équipe peuvent être dramatiques, une sorte de pression de la vitesse apparaît. Si on a déjà fait vite par le passé, on peut et on doit le refaire car les modèles et les outils évoluent. On ne peut plus inverser le mécanisme.

Un métier qui mute

On l'a vu, on peut passer de plus en plus de temps à relire le travail de nos collègues. Et de moins en moins de temps à produire nous-mêmes. Si nous travaillons dans un contexte où la phase de conception est ultra solide mais que nous n'y participons pas ou peu, que nous reste-t-il ?

Si on est dans un projet où l'architecture est solide, tout comme les outils, les dépendances, le design system. Si les tickets sont parfaitement écrits, les specs sont complètes (de plus en plus générés eux-mêmes par l'IA d'ailleurs), où pouvons-nous encore apporter de la valeur de la créativité si la part du code fond également ? La relecture et la critique ? Certainement.

Cela pose des questions qu'on essaiera de creuser par la suite, sur nos métiers qui mergent et sur la compétition à venir entre les Product Managers / Designers / Développeurs vs les Développeurs / Product Managers / Architectes vs les Designers / Développeurs / Product Managers.

On voit partout sur les réseaux sociaux des incantations à ouvrir le scope de nos compétences, histoire de survivre à l'IA. Chaque métier qui se sent en danger pousse sur les côtés pour élargir son spectre. On veut faire le métier de nos collègues grâce aux agents pour éviter notre remplacement. Le hic c'est que absolument tout le monde a ce meme reflexe, donc y'aura t-il de la place et surtout du travail intéressant pour tout le monde ?

Une folle cadence

Le fait n'est pas de dire qu'on ne peut pas suivre la cadence, que ça va trop vite, qu'on ne peut pas résister à la pression. Il ne faut pas exagérer non plus, nous sommes encore un métier très privilégié. Nous travaillons sur des chaises ergonomiques, avec des horaires corrects, et pour des salaires largement au-dessus de la moyenne.

Mais c'est plutôt de savoir comment on contrôle cette cadence, le flow, le rythme. Une pub célèbre dit "sans le contrôle, la vitesse n'est rien". Ou un truc dans le genre.

Quand la machine s'emballe, l'image qui peut venir c'est un peu Les Temps Modernes. C'est cette animation qui nous vient d'une chaîne de production à un rythme très soutenu qui déraille.

Quand les revues de code s'accumulent, quand les tickets également s'amoncèlent dans la colonne de tests, la chaîne ne s'arrête pas en urgence, la sirène ne retentit pas. C'est ce qui devrait se passer, mais bien souvent les colis s'accumulent juste en bout de tapis roulant.

Éloge du rythme de croisière

L'avantage lorsqu'on est un peu moins rapide, c'est qu'on peut freiner, on peut éviter les obstacles. Lorsqu'on prend de la vitesse, en revanche on prend aussi plus de risques. C'est plus grisant, certes. On est censé aussi être plus alerte, plus réactif, et qu'on peut se remettre d'un accident plus vite.

Alors peut-être que pour ceux qui ont tenté la vitesse, le freinage n'est plus possible. Mais pour ceux qui n'ont pas encore démarré, pour les projets encore sur la ligne de départ, il est encore temps de discuter ensemble du rythme soutenable sur lequel l'équipe est prête à s'engager.

L'IA est une aubaine pour accélérer et faire plus de choses, pour creuser la qualité, couvrir de plus grands contextes. Elle ne doit pas, à mon avis, servir juste à livrer plus vite et prendre plus de risques au volant.

Quelles solutions ?

Slow down !!! Ne transformons pas d’un coup nos épreuves de fond en sprints courts. Commençons par nous améliorer sur mi-distance et longue distance, battons des records dans ces disciplines et ensuite on pourra éventuellement changer de discipline et se mettre au 100m, voire aux sports mécaniques.