- ▸ Une note de mai 2026 qui prend l'industrie à contre-pied
- ▸ Thèse : la valeur s'est déplacée de l'écriture vers la revue
- ▸ Contexte historique : de Copilot à l'agent qui relit
- ▸ Analyse technique : la triangulation de modèles comme infrastructure de revue
La doxa veut que les assistants de code accélèrent la production. Nolan Lawson, ingénieur logiciel et auteur du blog éponyme, défend l’inverse dans une note publiée le 25 mai 2026 : utiliser plusieurs modèles d’IA pour ralentir volontairement la revue, multiplier les vérifications croisées, et produire moins de pull requests mais infiniment moins de bugs. La thèse mérite un détour analytique.
Points clés 1. Lawson documente une méthode où Claude, Codex et Bugbot sont mobilisés en parallèle pour auditer une même pull request, transformant l’IA en couche de revue plutôt qu’en moteur d’écriture. 2. La rapidité d’écriture n’est plus la métrique pertinente : la priorisation et la validation des signaux deviennent le goulot d’étranglement, selon la note du 25 mai 2026. 3. La triangulation entre modèles réduit mécaniquement le taux de faux positifs, sans qu’aucun chiffre public ne quantifie encore l’écart. 4. La revue produit tant de signalements qu’elle en devient « ennuyeuse à lire », d’après l’auteur — un renversement complet du discours dominant sur la productivité. 5. La rédaction d’un rapport final dans ses propres mots, après recherche personnelle, conditionne la qualité de l’ensemble.
Une note de mai 2026 qui prend l’industrie à contre-pied
Le 25 mai 2026, Nolan Lawson publie sur son blog personnel un texte intitulé Using AI to write better code more slowly. Le ton est posé, presque didactique. Aucun manifeste, aucune polémique frontale. Pourtant, l’argument central déstabilise un récit installé depuis deux ans : celui qui assimile productivité du développeur et vitesse de production de code généré.
Lawson n’est pas un commentateur extérieur. Il a passé une partie de sa carrière sur des projets logiciels exposés, et son audience technique le lit pour ses observations empiriques plus que pour ses opinions. La note s’ouvre sur une formule directe : « this comment is misleading », adressée à l’idée selon laquelle les assistants conversationnels servent surtout à fabriquer des pull requests à la chaîne. Cette phrase, isolée, condense la thèse : on regarde la mauvaise variable.
Thèse : la valeur s’est déplacée de l’écriture vers la revue
L’argument de Lawson tient en une bascule. Les modèles de génération de code — Claude d’Anthropic, Codex d’OpenAI, Bugbot — excellent à trouver des bugs dans des pull requests non vérifiées. Le problème n’est pas la détection. C’est la priorisation et la validation des findings. Conséquence opérationnelle : l’IA cesse d’être un compilateur amélioré pour devenir un binôme de revue, et le temps de cycle s’allonge volontairement.
Contexte historique : de Copilot à l’agent qui relit
Pour mesurer la rupture, il faut revenir à 2021. À cette date, GitHub publie Copilot, premier assistant de code grand public adossé à un modèle d’OpenAI. Le narratif vendu aux directions techniques tient en une équation : gain de vitesse de frappe, gain de productivité, gain économique. La métrique mise en avant par GitHub à l’époque est l’« acceptance rate » des suggestions, soit le pourcentage de lignes proposées que le développeur valide sans modification. L’optimisation porte sur le clavier.
Trois années passent. Les éditeurs spécialisés se multiplient — Cursor, Continue, Aider — et tous reconduisent le même cadre mental. Le développeur écrit, l’IA complète, on mesure des tokens par minute. Cette grammaire reste celle de l’éditeur de texte assisté, à peine déplacée vers un éditeur agentique.
Le tournant intervient avec l’apparition de modes opératoires plus longs. Les agents autonomes, capables d’enchaîner plusieurs étapes sans intervention humaine, ouvrent la possibilité de fabriquer des pull requests complètes à partir d’un ticket d’issue. Le revers s’impose vite : la quantité de code soumis à revue humaine explose, et la capacité de relecture des équipes ne suit pas. Le goulot d’étranglement migre vers la revue. C’est précisément le point qu’observe Lawson.
Cette migration n’a rien d’anecdotique. Elle inverse la métrique pertinente. Si la valeur ne réside plus dans la vitesse de production mais dans la rigueur de la revue, alors un assistant qui ralentit le développeur en élevant le seuil de qualité produit davantage de valeur qu’un assistant qui accélère la production de pull requests fragiles. La note du 25 mai 2026 est l’une des premières formulations explicites de ce renversement par un praticien.
Analyse technique : la triangulation de modèles comme infrastructure de revue
Le cœur opérationnel de la démarche tient en un pipeline. Lawson décrit avoir bâti une compétence Claude — une skill, dans le vocabulaire d’Anthropic — qui orchestre Codex et Bugbot. Le développeur soumet une pull request, et la compétence convoque les trois modèles en parallèle pour analyser le diff. Chaque modèle renvoie sa liste de problèmes identifiés. L’humain agrège, recoupe, et tranche.
Pourquoi trois modèles plutôt qu’un seul
L’intuition s’appuie sur une propriété statistique des erreurs de modèles génératifs : les faux positifs ne sont pas parfaitement corrélés. Un modèle peut halluciner une vulnérabilité inexistante ; deux modèles indépendants signalent rarement la même hallucination ; trois modèles convergents sur un même point produisent un signal exploitable. Lawson ne publie pas de quantification chiffrée du gain — il s’agit d’un retour d’expérience individuel, et l’auteur reste prudent sur la généralisation.
Tableau comparatif des trois outils mobilisés
| Outil | Éditeur | Mode d’invocation | Périmètre annoncé |
|---|---|---|---|
| Claude | Anthropic | Compétence personnalisée orchestrant le pipeline | Revue de diff, rédaction du rapport final |
| Codex | OpenAI | Appelé par la compétence Claude | Analyse de code, suggestions de correction |
| Bugbot | Cursor | Appelé par la compétence Claude | Détection de bugs sur pull request |
Le tableau est volontairement sec. Aucune mesure de précision, aucun taux de rappel publié par Lawson dans la note source. Le lecteur exigeant en déduira que la méthode décrite reste un protocole artisanal, non un benchmark reproductible. C’est précisément ce qui en fait l’intérêt : une pratique professionnelle documentée, à mi-chemin entre l’anecdote et la procédure.
Le moment de bascule : le rapport final écrit à la main
Le pipeline ne s’arrête pas à l’agrégation des trois sorties. Lawson insiste sur une étape souvent négligée : la rédaction d’un rapport final dans ses propres mots. Cette étape suppose une recherche personnelle, ligne par ligne, pour écarter les faux positifs. Elle suppose aussi de hiérarchiser les bugs réels selon leur criticité. C’est cette étape, manuelle, qui ralentit la cadence. Et c’est cette étape qui produit la qualité.
L’auteur précise un détail qui mérite attention : la compétence trouve tant de signalements qu’il en devient « ennuyeux de tous les relire ». La phrase, presque banale, dit beaucoup. Elle indique que le coût marginal de la détection a chuté presque à zéro, et que le coût marginal de la validation reste, lui, irréductiblement humain. La chaîne de valeur de l’ingénierie logicielle se reconfigure autour de cet écart.
Un chiffre-phare à inscrire au mur : zéro
Lawson ne publie aucun pourcentage. Le chiffre-phare implicite de la méthode est donc zéro : zéro garantie quantifiée, zéro benchmark public, zéro métrique de rappel. Ce vide statistique est lui-même un enseignement. Les outils d’audit de code par IA n’ont pas encore d’instrument de mesure standardisé, et chaque praticien construit son propre protocole. La note de Lawson est une contribution à la constitution lente d’un corpus de pratiques.
Impact terrain : trois conséquences pour les équipes d’ingénierie
La méthode décrite par Lawson, si elle se diffusait, déplacerait trois équilibres dans les organisations d’ingénierie. D’abord, la composition du temps développeur. Si la phase de revue assistée par IA absorbe plusieurs heures par pull request — le temps de relire trois sorties de modèles, de mener sa propre recherche, et d’écrire un rapport synthétique — alors le nombre de pull requests qu’un ingénieur expérimenté peut traiter par semaine baisse. Mais le taux de bugs en production baisse également, et c’est sur ce différentiel que se joue l’arbitrage.
Ensuite, la définition de la séniorité technique. La capacité à orchestrer plusieurs modèles, à lire leurs sorties critiquement, à distinguer un faux positif d’un vrai bug subtil, devient une compétence en soi. Elle ne s’acquiert ni dans les cours d’informatique classiques ni dans la documentation des éditeurs. Elle se forge par la pratique répétée et par l’exposition à des bugs réels rencontrés en revue.
Enfin, le rapport entre coût du calcul et coût humain. Faire tourner Claude, Codex et Bugbot sur chaque pull request a un coût en jetons facturés. Ce coût reste, à ce jour, faible devant le coût horaire d’un ingénieur senior. Mais il n’est pas négligeable, et il s’agrège vite à l’échelle d’une organisation de plusieurs centaines de développeurs. Les directions techniques qui adopteraient la méthode devront documenter cet arbitrage économique.
Le cas des projets open source maintenus à temps partiel
Lawson exerce dans un contexte de projets logiciels où la rigueur est valorisée et où le temps de cerveau humain est rare. Le pipeline qu’il décrit est précieux dans ce cadre : il permet à un mainteneur isolé d’absorber un flux de contributions externes sans dégrader la qualité. Pour les mainteneurs de bibliothèques open source notamment, qui voient affluer des pull requests générées par des contributeurs eux-mêmes assistés d’IA, la triangulation devient une ligne de défense.
Perspectives contradictoires : trois objections sérieuses
Le raisonnement de Lawson ne fait pas l’unanimité, et il convient de présenter les objections les plus solides sans les caricaturer.
Première objection : la dépendance accrue à trois fournisseurs externes. Mobiliser Claude, Codex et Bugbot, c’est inscrire son pipeline de revue dans trois roadmaps commerciales distinctes, avec trois grilles tarifaires et trois politiques de confidentialité. Les équipes opérant sous contrainte de souveraineté numérique — administrations européennes, secteurs régulés — y verront une régression. Une méthode qui repose sur l’agrégation de trois IA américaines ne s’exporte pas facilement vers un cadre où le code source ne peut sortir d’un périmètre maîtrisé.
Deuxième objection : le biais de confirmation entre modèles. Claude, Codex et Bugbot ne sont pas statistiquement indépendants. Ils sont entraînés sur des corpus partiellement chevauchants, sur des architectures Transformer aux propriétés voisines, et alignés sur des préférences humaines collectées dans des cadres analogues. Trois modèles peuvent partager les mêmes angles morts. La triangulation, alors, n’apporte pas la robustesse statistique qu’elle promet. C’est une limite que Lawson ne mentionne pas explicitement, et qu’un examen critique se doit de soulever.
Troisième objection : le risque de désengagement progressif de l’ingénieur humain. La méthode décrit un humain qui agrège, valide, écrit. Mais l’expérience montre que les développeurs exposés à des outils d’assistance prolongée tendent à atrophier leur lecture critique. Si le pipeline trouve tant de bugs qu’il devient « ennuyeux de tous les relire », alors la tentation de cliquer sans lire devient structurelle. C’est l’effet « pilote automatique » bien documenté dans d’autres secteurs. Lawson semble en avoir conscience puisqu’il insiste sur la rédaction d’un rapport personnel, mais l’objection demeure.
À ces trois objections s’ajoute une remarque méthodologique : un retour d’expérience individuel, aussi rigoureux soit-il, ne vaut pas étude contrôlée. Aucune comparaison rigoureuse n’a été publiée à ce jour entre un pipeline mono-modèle et un pipeline multi-modèles, sur des cohortes comparables de pull requests. Le récit de Lawson appelle des travaux empiriques pour être confirmé.
Prospective : vers une normalisation de la revue multi-modèles
Trois trajectoires plausibles se dessinent à dix-huit mois. Première trajectoire : les éditeurs intègrent nativement la triangulation. Cursor, GitHub, GitLab pourraient embarquer des pipelines multi-modèles dans leurs offres, transformant la pratique artisanale décrite par Lawson en fonctionnalité standard. Deuxième trajectoire : l’apparition d’outils de scoring de signalements, qui agrègent les sorties de modèles et produisent un indice de confiance unifié. L’humain n’arbitre plus entre trois listes, il consulte une liste pondérée. Troisième trajectoire, plus lente : la constitution de benchmarks publics de revue de code, qui permettront enfin de mesurer l’apport réel de chaque pipeline.
Une question reste ouverte : la rentabilité économique de la méthode dépendra du prix du jeton facturé par les fournisseurs. Si les coûts d’inférence baissent au rythme observé depuis 2023, la triangulation deviendra trivialement abordable. Si la trajectoire s’inverse — sous l’effet de contraintes énergétiques ou de tensions sur l’approvisionnement en accélérateurs — l’arbitrage redeviendra serré. Cette variable de second ordre conditionne pourtant la diffusion de la pratique au-delà des early adopters.
FAQ
Et si la méthode multi-modèles ne trouve aucun bug ?
D’après Lawson, le taux de faux positifs est très faible dans son expérience personnelle, mais le cas d’absence totale de signalements arrive. Il observe alors que la lecture des sorties reste éducative : voir comment chaque modèle aborde le diff donne des idées de réorganisation ou de tests supplémentaires. La méthode produit donc de la valeur même en cas de silence.
Comment rédige-t-on le rapport final après revue multi-modèles ?
Le rapport final s’écrit dans ses propres mots, après une recherche personnelle visant à écarter les faux positifs. Lawson recommande de hiérarchiser les bugs réels par criticité, puis de ne retenir que les plus importants dans la synthèse remise au demandeur de la pull request. La concision du rapport conditionne sa lecture effective.
La méthode fonctionne-t-elle pour les pull requests générées par IA ?
C’est précisément l’un des cas d’usage cités par Lawson. Les pull requests non vérifiées, qu’elles viennent de contributeurs humains pressés ou d’agents génératifs, sont le terrain où la triangulation montre sa valeur. Plus le code soumis a été produit sans relecture, plus la couche de revue automatisée justifie son coût.
Combien de temps faut-il pour adopter cette pratique ?
Lawson ne chiffre pas. La compétence Claude qu’il décrit a été configurée sur la base de l’outillage d’Anthropic, et l’adoption suppose un accès aux trois services et une certaine aisance avec les modes agentiques. Pour une équipe novice, un mois d’expérimentation semble un ordre de grandeur raisonnable, à confirmer empiriquement.
Encadré sources
- Nolan Lawson, Using AI to write better code more slowly, 25 mai 2026 — https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/
Anthropic et la course aux 1M de tokens — Pourquoi Cursor entraîne ses propres modèles — Codex et la maturité des agents OpenAI
