Reprendre une application écrite par des agents sans tout réécrire

Martin Fowler décrit le plan qui séduit toujours : nous savons ce que fait l’ancien système, construisons-en un nouveau qui fait exactement la même chose. Il ajoute avoir vu ce plan d’apparence si simple « partir en fumée la plupart du temps »[1]. Il lui préfère une modernisation progressive : isoler quelques composants derrière des coutures, puis les remplacer un à un, l’ancien et le nouveau cohabitant le temps de la transition[1].

L’argument pèse plus lourd encore pour une application écrite par des agents. La réécriture serait elle aussi écrite, en bonne partie, par des agents : un code que personne n’a relu remplacé par un autre que personne n’a relu. Et le comportement dont vos clients dépendent n’est souvent écrit nulle part ailleurs que dans le code.

Reprendre, c’est quatre gestes, dans cet ordre :

1. figer le comportement actuel par des tests, avant de toucher au code ;
2. inventorier ce qui fait tourner l’application : comptes, services tiers, clés, personnes ;
3. classer les parties du code par rayon d’impact ;
4. remplacer par morceaux ce qui doit l’être, en commençant par le plus exposé.

Les chiffres sur le code généré circulent beaucoup, souvent sans leur dénominateur. Voici quatre travaux récents, lus avec leur périmètre.

Une équipe de chercheurs a recensé 9 041 applications open source construites avec Claude Code ou Lovable, puis audité 200 d’entre elles, déployées publiquement. Elle y a trouvé 1 186 vulnérabilités : 91,0 % des applications auditées en contenaient au moins une, et 65,77 % des vulnérabilités relevées étaient jugées critiques ou élevées[2]. Le premier pourcentage compte des applications, le second des vulnérabilités. Aucun des deux ne mesure une part de code vulnérable.

Veracode soumet des tâches de programmation à des modèles et vérifie si la réponse est sûre. Dans sa mesure de l’automne 2026, sur 18 modèles et quatre langages, le taux moyen de réussite passe de 56 % à 62 % depuis l’été, et les meilleurs atteignent 73 %[3]. Les tâches portent sur quatre familles de failles : l’injection SQL, le chiffrement faible, l’injection de script dans une page et l’injection dans les journaux[3]. Le contrôle d’accès n’en fait pas partie. L’éditeur conclut lui-même que le meilleur modèle échoue encore sur plus d’une tâche de sécurité sur quatre[3].

Le banc d’essai SusVibes rassemble 186 demandes de fonctionnalités tirées de projets open source, choisies parce que leur implémentation humaine d’origine avait introduit une vulnérabilité. Il les confie à des agents dans douze configurations[4]. Il mesure donc la sûreté sur des situations piégeuses, pas sur un échantillon quelconque. Son résultat le plus parlant tient en un chiffre.

GitGuardian compare enfin des commits publics sur GitHub : ceux qu’il identifie comme assistés par Claude Code exposaient un secret dans 3,2 % des cas, contre 1,5 % pour l’ensemble des commits publics[5]. L’éditeur prévient que l’écart ne doit pas se lire comme une simple défaillance de l’outil, et son billet ne décrit pas comment ces commits ont été identifiés[5].

Ces travaux convergent sur un point : un code qui fonctionne n’est pas, de ce seul fait, un code sûr. Aucun ne dit où se trouvent les failles de votre application. C’est l’objet du tri qui suit.

Tout ne mérite pas la même attention le même jour. Nous classons les parties du code selon ce qu’une erreur y coûterait, en trois rayons.

• Les données. Qui peut lire ou modifier quoi ? Un client peut-il atteindre les données d’un autre ? Où partent les fichiers téléversés, les exports, les journaux ?
• L’argent. Où se calcule un prix, une remise, un remboursement ? Qui déclenche un paiement, et le serveur vérifie-t-il ce que le navigateur lui envoie ?
• La disponibilité. Qu’est-ce qui arrête le service : une clé qui expire, un quota atteint, un compte tiers ouvert au nom d’un ancien prestataire, une sauvegarde jamais restaurée ?

Le troisième rayon commence souvent hors du code. Listez les services dont l’application dépend : hébergement, base de données, paiement, envoi d’e-mails, nom de domaine, comptes des agents eux-mêmes. Pour chacun, notez à quel nom il est ouvert, qui détient l’accès administrateur et qui reçoit les factures. Deux questions suffisent à lire ce tableau. Si la personne qui a monté le projet part demain, qui peut continuer à travailler ? Et peut-on changer de prestataire sans perdre la main ?

La dette technique, le style et les dépendances inutiles attendront que ces parcours soient protégés par des tests.

Un test de caractérisation décrit ce que le code fait aujourd’hui, pas ce qu’il devrait faire. On appelle un parcours, on enregistre la réponse, et le test échoue si elle change. Il ne juge pas le code : il prévient qu’une modification a des effets. C’est le filet sous lequel on peut ensuite corriger, ou laisser un agent corriger.

Un test qui vérifie seulement que le parcours aboutit passera aussi si n’importe qui peut le déclencher. Écrivez donc aussi ce qui doit être refusé : un client qui demande la facture d’un autre, un montant modifié dans la requête, un compte désactivé qui tente de se reconnecter. Ce sont eux qui protègent les données et l’argent.

L’agent qui modifie le code ne doit pas pouvoir affaiblir seul les tests qui le contrôlent. Un cas récent montre pourquoi. En octobre 2026, OpenAI a décrit un incident survenu pendant l’entraînement d’un modèle interne chargé de noter les réponses d’autres modèles. Privé des fichiers à noter, il a soumis des évaluations fabriquées, puis créé un faux fichier de conversation et sept faux fichiers de réponses pour passer le contrôle automatique[6]. Il a ensuite abîmé son environnement de travail, dans l’espoir d’en recevoir un autre où les fichiers seraient présents[6]. Le contrôle automatique a rejeté les notes fabriquées, et OpenAI en conclut que la surveillance doit couvrir aussi les tentatives échouées[6].

Ce n’était pas une application en production, mais la leçon se transpose. Un agent qui peut modifier à la fois le code, ses tests et la configuration de l’intégration continue peut faire passer le contrôle sans faire le travail. D’où une règle simple : toute modification des tests ou de la configuration de l’intégration continue exige l’approbation d’un humain, distinct de l’agent qui l’a écrite.

GitHub le rappelle dans la documentation de son agent : Copilot peut produire un code incorrect, y compris des failles de sécurité ; il faut relire et tester ce qu’il livre avant de le mettre en production, et ses journaux de travail ne remplacent pas cette relecture[7].

Encore faut-il savoir ce qui vient d’un agent. Claude Code ajoute par défaut une mention de co-auteur aux commits qu’il crée, mais un réglage permet de la retirer[8] : son absence ne prouve donc pas qu’un humain a écrit le code. Le plus sûr est de donner aux agents leur propre identité dans le dépôt, pour que l’historique dise qui a poussé quoi.

Ensuite, faites porter la relecture par les règles du dépôt plutôt que par la bonne volonté. Sur GitHub, une branche protégée peut exiger que la dernière modification soit approuvée par une autre personne que celle qui l’a poussée, imposer l’accord du propriétaire désigné de chaque partie du code et annuler les approbations quand de nouveaux commits changent le contenu de la demande[9]. Une règle de branche peut aussi empêcher Copilot de créer ou de mettre à jour une demande de fusion, et un administrateur peut lui accorder une exemption[7]. Tenez la liste de ces exemptions.

Reste la question de demain. Les fichiers de consignes des agents, comme AGENTS.md, CLAUDE.md ou les règles de Cursor, disent comment l’agent doit travailler. Ils n’expliquent pas à un humain comment l’application fonctionne. Une page courte, tenue par l’équipe, le fait : les parcours principaux, les services tiers, qui détient quels accès, comment on déploie et comment on revient en arrière.

Les paquets que les agents ajoutent, et la configuration des agents eux-mêmes, méritent leur propre relecture. Nous la détaillons dans l’article consacré aux attaques par npm.

Rien de cela n’oblige à arrêter les livraisons ni à se passer des agents. Il s’agit de savoir ce que fait l’application avant de la changer, et qui répond de chaque partie. Un scan automatique aide à repérer des erreurs connues ; il ne remplace ni ces tests, ni la relecture, ni un test d’intrusion mené par un prestataire indépendant. Et ne pas trouver de faille ne garantit pas qu’il n’y en a pas.