Laissons tomber le ton poli : le jugement n'a jamais été un nouveau goulot d'étranglement en génie logiciel. C'est le plus vieux de tous. Ce qui a changé, c'est que les agents de codage IA ont fait tomber l'excuse comme quoi écrire le code était la partie difficile, du coup ce en quoi on a toujours été médiocre — décider si un bout de code mérite vraiment d'exister en production — se retrouve à poil, sans plus aucun endroit où se cacher.

Prends l'histoire de Grok Build ce mois-ci. xAI a rendu open source le harnais et l'interface terminal qui tournent derrière, permettant à n'importe qui d'inspecter comment il assemble le contexte et déclenche les appels d'outils, ce qui est une transparence sincèrement utile. Mais cette sortie a suivi des rapports selon lesquels l'assistant uploadait plus de données du repo que ce que n'importe quelle tâche exigeait, l'entreprise promettant de supprimer des données clients qu'un chercheur avait retrouvées qui traînaient dans son stockage cloud. Traduit en termes de boutique PHP : ton composer.lock, ton .env.example que quelqu'un a oublié de vraiment gitignorer, tes seeders de base de données pleins de données de test à l'apparence bien réelle, les identifiants de ton miroir privé Satis ou Packagist. L'open source te dit que le code peut être lu. Il ne te dit rien sur ce qu'une version hébergée de ce code fait de ton arborescence une fois que tu la pointes vers ton repo.

Voici le contre-argument honnête, et je ne pense pas que ce soit un épouvantail facile : beaucoup d'équipes PHP vont dire « d'accord, il suffit de délimiter ce que l'agent peut lire et écrire ». Ça paraît simple jusqu'à ce que tu te rappelles à quoi ressemble vraiment un monorepo Laravel ou Symfony hérité — des migrations posées à côté de fixtures seedées, elles-mêmes à côté d'un dossier de config qui charge tranquillement des secrets depuis trois endroits différents selon l'environnement. Tracer une frontière lecture/écriture propre autour de ce bazar est en soi une vraie tâche d'ingénierie, pas une case à cocher dans le panneau de réglages de ton agent.

Voici la partie qui devrait t'inquiéter bien plus que n'importe quel scandale de gestion des données. Un preprint de juillet a fait juger par 86 programmeurs Python des assertions de tests générées par IA : ils ont correctement identifié les bonnes 74 % du temps, mais n'ont repéré les mauvaises que 49 % du temps — pile ou face — tout en déclarant un niveau de confiance identique dans les deux cas. C'est un preprint, prends les chiffres comme préliminaires, mais la forme du résultat sonne vrai pour quiconque a relu une PR générée par un agent, pleine d'un formatage PSR-12 impeccable, de relations Eloquent plausibles, et d'un message de commit confiant expliquant exactement ce qu'il a « corrigé ». Du code fluide se lit comme du code correct. C'est le piège, et il se fiche complètement du langage dans lequel tu écris.

Alors qu'est-ce qu'on fait concrètement de ça. L'article source propose quatre limites à poser avant même de choisir un outil — contexte, autorité, preuve, approbation — et je pense que cet instinct est juste mais qu'il lui faut des dents plus acérées pour nous, spécifiquement. La preuve ne peut pas juste vouloir dire un PHPUnit vert. Une suite de tests qui passe ne détectera pas un calcul de TVA subtilement faux, et elle ne détectera certainement pas la requête N+1 qu'un agent a introduite, qui a l'air impeccable sur une base de dev seedée avec douze lignes et qui fait ensuite fondre tes workers de queue à 90 % de CPU face aux données de production, trois semaines plus tard. Si ta barre de preuve, c'est « les tests passent », tu n'as pas de barre.

Je nuancerais aussi gentiment l'idée que c'est surtout un problème de choix d'outil — Claude Code contre Cursor contre Codex contre Grok Build. Un meilleur harnais collé sur une équipe sans vraie culture de revue, c'est juste une couche de peinture plus jolie sur la même fuite. Les équipes qui vont vraiment tirer parti de ces agents ne sont pas celles avec l'interface de permissions la plus sophistiquée, ce sont celles qui savaient déjà mener une revue de code rigoureuse avant que tout ça n'existe, et qui appliquent maintenant cette même discipline à un flux de diffs beaucoup plus rapide.

Concrètement, ça veut dire hiérarchiser les risques dans ton propre workflow plutôt que de traiter chaque PR générée de la même façon. Un agent qui refond un composant de landing page marketing peut passer par une revue légère. Un agent qui touche à ta logique de facturation, à ton middleware d'authentification, ou à tout ce qui écrit dans une table de grand livre a besoin de tests de contrat, d'un second humain, et honnêtement d'une bonne dose de suspicion, peu importe à quel point son explication sonne confiant — parce que la confiance, d'après ce preprint, est exactement le signal auquel tu ne peux pas te fier.

Voici donc ma vraie question pour toi, pas une question rhétorique : ton équipe a-t-elle tracé de vraies limites autour de ce qu'un agent de codage a le droit de toucher dans ton repo, ou est-ce que tu comptes en ce moment sur une pipeline CI verte comme unique filet de sécurité ? J'aimerais vraiment savoir à quoi ressemble ton portail de revue une fois que le volume de PR de l'agent est multiplié par dix, parce que le mien est encore un chantier en cours.