La revue de code exhaustive est peut-\u00eatre devenue le nouveau travail administratif des d\u00e9veloppeurs.<\/p>\n\n\n\n
Le raisonnement traditionnel para\u00eet pourtant irr\u00e9prochable.<\/p>\n\n\n\n
Une intelligence artificielle produit le code. Un humain relit chaque ligne. Il v\u00e9rifie la syntaxe, les conventions, les appels de fonctions, les structures de donn\u00e9es et les commentaires. Ensuite seulement, le code peut \u00eatre accept\u00e9.<\/p>\n\n\n\n
Cette m\u00e9thode rassure les responsables techniques. Elle prot\u00e8ge les habitudes. Elle donne surtout l\u2019impression que l\u2019humain conserve le contr\u00f4le.<\/p>\n\n\n\n
Puis arrive un probl\u00e8me tr\u00e8s concret : le volume.<\/p>\n\n\n\n
Antirez pose une question volontairement provocatrice : comment un d\u00e9veloppeur pourrait-il relire s\u00e9rieusement 5 000 lignes de code g\u00e9n\u00e9r\u00e9es chaque jour ?<\/p>\n\n\n\n
Le temps consacr\u00e9 \u00e0 cette inspection est n\u00e9cessairement retir\u00e9 \u00e0 une autre activit\u00e9 : conception, architecture, s\u00e9curit\u00e9, performance, compr\u00e9hension du besoin, exp\u00e9rience utilisateur ou recherche des conditions de rupture. (Antirez<\/a>)<\/p>\n\n\n\n L\u2019IA ne supprime donc pas le travail. Elle r\u00e9v\u00e8le les activit\u00e9s dont nous avions mal d\u00e9fini la valeur.<\/p>\n\n\n\n Les outils d\u2019assistance au d\u00e9veloppement permettent d\u00e9j\u00e0 de produire certaines fonctions beaucoup plus rapidement.<\/p>\n\n\n\n Dans une exp\u00e9rience contr\u00f4l\u00e9e men\u00e9e par GitHub aupr\u00e8s de 95 d\u00e9veloppeurs professionnels, le groupe utilisant Copilot a termin\u00e9 une t\u00e2che de programmation 55 % plus rapidement en moyenne que le groupe sans Copilot.<\/p>\n\n\n\n Ce r\u00e9sultat porte sur un exercice pr\u00e9cis et ne peut pas \u00eatre automatiquement g\u00e9n\u00e9ralis\u00e9 \u00e0 tous les projets, mais il illustre clairement l\u2019acc\u00e9l\u00e9ration possible de la production. (GitHub<\/a>)<\/p>\n\n\n\n Or une cha\u00eene de production ne devient pas plus performante simplement parce que l\u2019une de ses machines acc\u00e9l\u00e8re.<\/p>\n\n\n\n Si le code est g\u00e9n\u00e9r\u00e9 cinq fois plus vite, mais que les revues, les validations de s\u00e9curit\u00e9, les tests et les mises en production fonctionnent toujours selon les anciens rythmes, le gain individuel se transforme en embouteillage collectif.<\/p>\n\n\n\n Les travaux de DORA montrent pr\u00e9cis\u00e9ment cette tension.<\/p>\n\n\n\n Dans les donn\u00e9es \u00e9tudi\u00e9es, une augmentation de 25 % de l\u2019adoption de l\u2019IA \u00e9tait associ\u00e9e \u00e0 une baisse de 1,5 % du d\u00e9bit de livraison et de 7,2 % de la stabilit\u00e9.<\/p>\n\n\n\n DORA avance notamment l\u2019explication de lots de changements plus volumineux, plus longs \u00e0 examiner et plus susceptibles de d\u00e9stabiliser le syst\u00e8me. (DORA<\/a>)<\/p>\n\n\n\n Voil\u00e0 le paradoxe : les d\u00e9veloppeurs peuvent avoir le sentiment d\u2019aller plus vite tandis que l\u2019organisation livre moins efficacement.<\/p>\n\n\n\n L\u2019IA amplifie ici une faiblesse ancienne.<\/p>\n\n\n\n Beaucoup d\u2019entreprises mesurent encore l\u2019activit\u00e9 logicielle \u00e0 travers le nombre de lignes produites, de tickets termin\u00e9s, de fonctionnalit\u00e9s d\u00e9velopp\u00e9es ou de demandes de fusion soumises.<\/p>\n\n\n\n Quand la production devient abondante, ces indicateurs r\u00e9compensent le volume qui finit par saturer le reste du syst\u00e8me.<\/p>\n\n\n\n Relire chaque ligne semble \u00eatre une m\u00e9thode rigoureuse.<\/p>\n\n\n\n Pourtant, la rigueur ne consiste pas \u00e0 consacrer la m\u00eame attention \u00e0 chaque d\u00e9tail.<\/p>\n\n\n\n Une faute dans une fonction d\u2019affichage, une erreur dans un syst\u00e8me d\u2019autorisation et une incoh\u00e9rence dans un algorithme de calcul financier ne portent pas le m\u00eame risque.<\/p>\n\n\n\n Les traiter avec un effort identique revient \u00e0 confondre \u00e9galit\u00e9 de traitement et qualit\u00e9 du contr\u00f4le.<\/p>\n\n\n\n Les pratiques de revue publi\u00e9es par Google recommandent de commencer par une vision globale du changement.<\/p>\n\n\n\n Le changement est-il pertinent ?<\/p>\n\n\n\n Est-il correctement d\u00e9crit ?<\/p>\n\n\n\n Est-il coh\u00e9rent avec la direction g\u00e9n\u00e9rale du syst\u00e8me ?<\/p>\n\n\n\n Le reviewer doit ensuite examiner les parties les plus importantes et les probl\u00e8mes de conception avant de parcourir le reste du changement.<\/p>\n\n\n\n Une faiblesse architecturale majeure peut rendre inutile l\u2019analyse d\u00e9taill\u00e9e de nombreuses lignes qui devront de toute fa\u00e7on \u00eatre r\u00e9\u00e9crites. (Google Engineering Practices<\/a>)<\/p>\n\n\n\n Google rappelle \u00e9galement que l\u2019objectif principal d\u2019une revue consiste \u00e0 am\u00e9liorer progressivement la sant\u00e9 globale du code, pas \u00e0 atteindre une perfection abstraite sur chaque modification.<\/p>\n\n\n\n Les donn\u00e9es et les faits techniques doivent l\u2019emporter sur les pr\u00e9f\u00e9rences personnelles. (Google Engineering Practices<\/a>)<\/p>\n\n\n\n La revue ligne par ligne peut facilement d\u00e9river vers des d\u00e9bats de style, de nommage ou de pr\u00e9f\u00e9rence personnelle tandis que des interrogations beaucoup plus importantes restent sans r\u00e9ponse.<\/p>\n\n\n\n Le logiciel r\u00e9pond-il au bon probl\u00e8me ?<\/p>\n\n\n\n Le mod\u00e8le de donn\u00e9es est-il coh\u00e9rent ?<\/p>\n\n\n\n Le syst\u00e8me continuera-t-il \u00e0 fonctionner sous une charge dix fois sup\u00e9rieure ?<\/p>\n\n\n\n Les autorisations sont-elles contr\u00f4l\u00e9es \u00e0 tous les points critiques ?<\/p>\n\n\n\n Une d\u00e9faillance partielle peut-elle contaminer tout le service ?<\/p>\n\n\n\n Le changement duplique-t-il une fonction d\u00e9j\u00e0 pr\u00e9sente ailleurs ?<\/p>\n\n\n\n La revue exhaustive devient alors une c\u00e9r\u00e9monie de contr\u00f4le.<\/p>\n\n\n\n Elle produit beaucoup de commentaires visibles, sans n\u00e9cessairement concentrer l\u2019attention sur les risques d\u00e9cisifs.<\/p>\n\n\n\n L\u2019approche propos\u00e9e par Antirez consiste \u00e0 contr\u00f4ler les id\u00e9es contenues dans le logiciel plut\u00f4t que de consid\u00e9rer le code comme le seul objet intellectuel du d\u00e9veloppeur.<\/p>\n\n\n\n Cette proposition ne signifie pas que le code devient sans importance.<\/p>\n\n\n\n Elle sugg\u00e8re une hi\u00e9rarchie diff\u00e9rente du contr\u00f4le.<\/p>\n\n\n\n Un syst\u00e8me logiciel est d\u2019abord une repr\u00e9sentation d\u2019un probl\u00e8me et d\u2019une solution.<\/p>\n\n\n\n Le code mat\u00e9rialise cette repr\u00e9sentation dans un langage ex\u00e9cutable.<\/p>\n\n\n\n Une impl\u00e9mentation \u00e9l\u00e9gante d\u2019un mauvais mod\u00e8le reste un mauvais logiciel.<\/p>\n\n\n\n Le premier niveau de contr\u00f4le doit donc porter sur le design.<\/p>\n\n\n\n Pourquoi cette architecture a-t-elle \u00e9t\u00e9 choisie ?<\/p>\n\n\n\n Quelles autres options ont \u00e9t\u00e9 \u00e9tudi\u00e9es ?<\/p>\n\n\n\n O\u00f9 sont plac\u00e9es les responsabilit\u00e9s ?<\/p>\n\n\n\n Quels compromis ont \u00e9t\u00e9 accept\u00e9s entre simplicit\u00e9, performance, co\u00fbt, s\u00e9curit\u00e9 et \u00e9volutivit\u00e9 ?<\/p>\n\n\n\n Quelles d\u00e9pendances externes deviennent critiques ?<\/p>\n\n\n\n Quelles d\u00e9cisions seront difficiles \u00e0 inverser ?<\/p>\n\n\n\n Une IA peut produire des milliers de lignes localement coh\u00e9rentes tout en construisant progressivement un syst\u00e8me globalement incoh\u00e9rent.<\/p>\n\n\n\n Le d\u00e9veloppeur exp\u00e9riment\u00e9 apporte ici quelque chose que le mod\u00e8le ne poss\u00e8de pas n\u00e9cessairement : l\u2019histoire du produit, les incidents pass\u00e9s, les contraintes op\u00e9rationnelles, les usages r\u00e9els des clients, les compromis d\u00e9j\u00e0 refus\u00e9s et les risques sp\u00e9cifiques \u00e0 l\u2019organisation.<\/p>\n\n\n\n Cette connaissance contextuelle devient une partie centrale du travail.<\/p>\n\n\n\n Le deuxi\u00e8me niveau consiste \u00e0 formaliser les invariants.<\/p>\n\n\n\n Un invariant est une propri\u00e9t\u00e9 qui doit rester vraie, quelles que soient les modifications apport\u00e9es au logiciel.<\/p>\n\n\n\n Un compte bancaire ne doit pas cr\u00e9er spontan\u00e9ment de l\u2019argent.<\/p>\n\n\n\n Un utilisateur ne doit pas acc\u00e9der aux donn\u00e9es d\u2019un autre utilisateur sans autorisation.<\/p>\n\n\n\n Une commande pay\u00e9e ne doit pas redevenir impay\u00e9e \u00e0 cause d\u2019une r\u00e9p\u00e9tition de message.<\/p>\n\n\n\n Une op\u00e9ration rejou\u00e9e apr\u00e8s une panne ne doit pas provoquer un doublon.<\/p>\n\n\n\n Une mise \u00e0 jour partielle ne doit pas laisser les donn\u00e9es dans un \u00e9tat contradictoire.<\/p>\n\n\n\n Ces propri\u00e9t\u00e9s d\u00e9crivent mieux la qualit\u00e9 du syst\u00e8me qu\u2019une inspection uniforme de sa syntaxe.<\/p>\n\n\n\n L\u2019\u00e9quipe doit donc demander \u00e0 l\u2019IA de produire du code, mais \u00e9galement de proposer des tests destin\u00e9s \u00e0 attaquer ces invariants.<\/p>\n\n\n\n Elle doit chercher les cas limites, les s\u00e9quences improbables, les probl\u00e8mes de concurrence, les erreurs de permission, les d\u00e9passements de capacit\u00e9 et les \u00e9tats interm\u00e9diaires.<\/p>\n\n\n\n Le r\u00f4le humain consiste \u00e0 d\u00e9terminer ce qui doit absolument rester vrai.<\/p>\n\n\n\n La machine peut ensuite aider \u00e0 multiplier les tentatives pour d\u00e9montrer que cette propri\u00e9t\u00e9 pourrait devenir fausse.<\/p>\n\n\n\n Une gouvernance plus mature du code g\u00e9n\u00e9r\u00e9 par IA peut s\u2019appuyer sur plusieurs couches compl\u00e9mentaires.<\/p>\n\n\n\n La premi\u00e8re est la validation fonctionnelle.<\/p>\n\n\n\n Le logiciel accomplit-il r\u00e9ellement ce qui a \u00e9t\u00e9 demand\u00e9 ?<\/p>\n\n\n\n La deuxi\u00e8me est la validation des cas limites.<\/p>\n\n\n\n Que se passe-t-il avec une donn\u00e9e absente, une valeur maximale, une r\u00e9ponse lente, une interruption r\u00e9seau ou deux op\u00e9rations simultan\u00e9es ?<\/p>\n\n\n\n La troisi\u00e8me est la validation comparative.<\/p>\n\n\n\n L\u2019impl\u00e9mentation peut-elle \u00eatre compar\u00e9e \u00e0 une version de r\u00e9f\u00e9rence, \u00e0 une biblioth\u00e8que reconnue ou \u00e0 un calcul ind\u00e9pendant ?<\/p>\n\n\n\n La quatri\u00e8me est la validation de performance.<\/p>\n\n\n\n Comment \u00e9voluent la consommation de m\u00e9moire, le temps de r\u00e9ponse, les co\u00fbts d\u2019infrastructure et la stabilit\u00e9 lorsque le volume augmente ?<\/p>\n\n\n\n La cinqui\u00e8me est la validation de s\u00e9curit\u00e9.<\/p>\n\n\n\n Les d\u00e9pendances, les entr\u00e9es, les permissions, les secrets, les flux de donn\u00e9es et les configurations doivent \u00eatre examin\u00e9s avec des outils sp\u00e9cialis\u00e9s et des audits proportionn\u00e9s au risque.<\/p>\n\n\n\n Le Secure Software Development Framework du NIST recommande d\u2019int\u00e9grer explicitement les pratiques de s\u00e9curit\u00e9 au cycle de d\u00e9veloppement, car de nombreux mod\u00e8les de d\u00e9veloppement ne les traitent pas suffisamment par d\u00e9faut. (NIST<\/a>)<\/p>\n\n\n\n L\u2019automatisation ne justifie donc pas une confiance aveugle.<\/p>\n\n\n\n Elle permet plut\u00f4t de d\u00e9placer une partie du contr\u00f4le humain vers la conception des m\u00e9canismes de validation.<\/p>\n\n\n\n L\u2019un des risques les plus int\u00e9ressants du code g\u00e9n\u00e9r\u00e9 par IA est son apparence de propret\u00e9.<\/p>\n\n\n\n Un code bien pr\u00e9sent\u00e9, correctement nomm\u00e9 et abondamment comment\u00e9 inspire facilement confiance.<\/p>\n\n\n\n Cette fluidit\u00e9 visuelle peut masquer une faiblesse de raisonnement, une permission oubli\u00e9e, une condition de concurrence ou une mauvaise compr\u00e9hension d\u2019une API.<\/p>\n\n\n\n Une \u00e9tude empirique portant sur 733 extraits attribu\u00e9s \u00e0 plusieurs assistants de programmation a identifi\u00e9 des faiblesses de s\u00e9curit\u00e9 dans 29,5 % des extraits Python et 24,2 % des extraits JavaScript analys\u00e9s.<\/p>\n\n\n\n Les auteurs pr\u00e9cisent la m\u00e9thode et les limites de leur \u00e9chantillon, qui ne permettent pas de transformer ces r\u00e9sultats en taux universels pour tout code g\u00e9n\u00e9r\u00e9.<\/p>\n\n\n\n Ils montrent n\u00e9anmoins que la correction fonctionnelle apparente et la s\u00e9curit\u00e9 sont deux sujets distincts. (arXiv<\/a>)<\/p>\n\n\n\n GitHub alerte \u00e9galement sur plusieurs comportements \u00e0 surveiller dans les demandes de fusion g\u00e9n\u00e9r\u00e9es par des agents : affaiblissement des contr\u00f4les d\u2019int\u00e9gration continue, suppression ou contournement de tests, duplication de fonctions existantes et code qui passe les tests tout en restant logiquement incorrect dans certaines situations.<\/p>\n\n\n\n GitHub indique que son syst\u00e8me de revue Copilot avait d\u00e9j\u00e0 trait\u00e9 plus de 60 millions de revues et que plus d\u2019une revue sur cinq sur la plateforme impliquait alors un agent.<\/p>\n\n\n\nLe code acc\u00e9l\u00e8re, l\u2019organisation ralentit<\/h2>\n\n\n\n
La revue exhaustive donne une illusion de ma\u00eetrise<\/h2>\n\n\n\n
Contr\u00f4ler les id\u00e9es avant de contr\u00f4ler la syntaxe<\/h2>\n\n\n\n
D\u00e9finir les invariants du syst\u00e8me<\/h2>\n\n\n\n
Remplacer la lecture exhaustive par une validation multicouche<\/h2>\n\n\n\n
Un code lisible peut rester dangereux<\/h2>\n\n\n\n