Code généré par IA : qui vérifie les tests ?

Une application produite avec l’aide de l’IA arrive avec ses écrans, sa documentation et une suite de tests entièrement verte. Pourtant, un responsable peut approuver une demande qui appartient à une autre société. Le problème n’est pas l’absence de tests : ceux-ci reproduisent la même interprétation incomplète que le code. Ajouter davantage de cas similaires ne corrige pas cette erreur de départ.

Le risque est de croire que deux fichiers cohérents apportent deux preuves indépendantes. Si le résultat attendu est calculé à partir de la fonction que l’on teste, ou si les deux suivent une règle inventée pendant la génération, leur accord ne dit rien sur le besoin réel. Il faut une référence extérieure à cette boucle.

Le développement d’une application web métier doit relier chaque décision importante à une règle acceptée, à des exemples contradictoires et à une preuve observable. L’origine humaine ou assistée du code ne change pas ce besoin. La génération rapide rend simplement plus facile l’accumulation de fonctions et de tests avant que les ambiguïtés soient arbitrées.

Nous suivrons un circuit d’approbation fictif pour montrer comment vérifier les résultats attendus, les limites et la capacité de détection. Les sources techniques sont vérifiées au 23 octobre 2026. L’exercice local porte sur une petite règle isolée ; il ne constitue ni l’audit d’une application cliente, ni une certification de sécurité, ni une mesure de fiabilité d’un modèle d’IA. Un audit technique de l’application doit donc examiner les règles qui fondent les assertions, autant que le nombre de tests exécutés.

Pourquoi le code et ses tests peuvent se tromper ensemble

Un assistant reçoit une demande : « un responsable approuve les dépenses jusqu’à mille euros ». Il doit choisir une interprétation du seuil, du rôle et du périmètre. Si personne ne précise la société concernée, le code peut vérifier uniquement le rôle. Une génération de tests fondée sur ce code produit ensuite des exemples qui confirment exactement cette logique.

Ce mécanisme n’exige aucune défaillance spectaculaire. Le code compile, les assertions sont correctes au regard de leur préparation et la démonstration fonctionne avec le compte utilisé. L’erreur se situe dans la règle retenue. La revue doit donc examiner la provenance du résultat attendu avant de compter les scénarios.

Reconnaître les assertions qui se contentent de recopier

Une assertion fragile utilise la même fonction de calcul pour construire l’attendu et pour obtenir le résultat. Une autre vérifie seulement que la réponse possède un champ « accepté ». Une troisième compare une capture enregistrée lors de la première exécution sans que personne ait vérifié ce qu’elle contient.

Ces contrôles peuvent protéger une forme ou une stabilité. Ils ne prouvent pas nécessairement la décision métier. Nommez leur portée exacte, puis ajoutez une référence indépendante pour les propriétés importantes : montant, autorité, état final ou nombre d’effets. La cohérence interne devient alors une preuve parmi d’autres, avec une limite connue.

Construire le résultat attendu avant de regarder l’implémentation

La référence de décision, parfois appelée oracle de test, répond à une question simple : pour ces données, quel résultat doit être obtenu et pourquoi ? Elle peut venir d’une règle métier signée, d’un exemple calculé à la main, d’un contrat d’interface ou d’une exigence de sécurité. Elle doit pouvoir être discutée sans lire la fonction testée.

Le responsable métier explique la règle ; le développeur ou la QA la transforme en cas exécutables. Les désaccords restent visibles. Si « jusqu’à mille » signifie une borne incluse pour les métiers mais exclusive dans le code, l’équipe ne doit pas corriger l’attendu pour rendre le test vert avant d’avoir tranché.

Conserver la preuve de l’arbitrage

Chaque famille de cas référence une version de règle, un propriétaire et une conséquence. Pour notre exemple, la règle R3 concerne uniquement des demandes en euros d’une même société, soumises et d’un montant strictement positif. Un responsable de cette société peut approuver jusqu’à 1 000 euros inclus ; au-delà, la demande est orientée vers une validation complémentaire.

Ce sont des choix fictifs, pas une recommandation comptable ou un standard universel. Dans un projet réel, la règle pourrait exiger deux approbateurs, interdire l’auto-approbation ou varier par établissement. Ces différences doivent être décidées avant que la suite prétende vérifier un processus complet.

Sept demandes qui distinguent vraiment les interprétations

Les montants suivants sont fournis en centimes d’euro. Nous utilisons des entiers pour éviter qu’une représentation approchée ne brouille l’exercice. Les données par défaut sont une demande soumise, un responsable habilité et une même société. Chaque ligne change uniquement la propriété indiquée.

La borne B apporte une information que A et C ne donnent pas ensemble : mille euros sont inclus dans l’autorisation. E distingue le rôle global d’une permission sur un objet précis. F prouve que l’état du dossier compte. G empêche une valeur par défaut de devenir une approbation apparemment légitime.

Les sept cas ne couvrent pas toutes les combinaisons. Ils évitent volontairement de décider la priorité entre plusieurs erreurs simultanées. Une demande étrangère, en brouillon et de montant nul exige un autre choix sur le message exposé. Le résultat doit notamment éviter de révéler des informations auxquelles l’acteur n’a pas accès.

Dans le scénario, le seuil de 1 000 euros détermine donc une action différente, pas une statistique décorative. Un centime au-dessus conduit à une validation complémentaire. Changer cette limite modifie la règle R3 et demande une nouvelle décision métier ; ce n’est pas une simple mise à jour des données du test.

Introduire des défauts ciblés pour vérifier la force des tests

Une suite qui reste verte lorsque l’on retire un contrôle important ne démontre pas ce contrôle. Sur la petite règle de l’exercice, on peut remplacer la borne inclusive par une borne stricte, supprimer la comparaison de société ou autoriser les brouillons. Chaque modification doit être détectée par un cas prévu.

Cette démarche doit rester confinée à une copie de test. Il ne s’agit pas d’injecter des défauts dans un service en production. Le code volontairement incorrect ne doit jamais rejoindre une image publiée ni un environnement contenant des opérations réelles.

Lire les mutants au lieu de poursuivre un pourcentage

La documentation Stryker sur les états et métriques de mutation distingue notamment mutation détectée, survivante, non couverte et erreur d’exécution. Un échec de compilation n’a pas la même signification qu’une assertion qui détecte une mauvaise décision. L’interprétation du rapport compte autant que le score affiché.

Pour R3, nous proposons quatre défauts : seuil devenu strict, contrôle de société retiré, contrôle d’état retiré et zéro accepté. B, E, F et G doivent respectivement les signaler. Cela vérifie la sensibilité de ces exemples à ces quatre erreurs ; cela ne démontre pas l’absence de toute autre erreur dans une application.

Une mutation survivante mérite une investigation. Le cas manque-t-il, l’assertion observe-t-elle la mauvaise chose, ou la modification est-elle sans effet sur le comportement attendu ? Documentez cette réponse avant d’exclure le mutant. Une exclusion sans motif peut masquer exactement la règle que l’équipe cherchait à protéger.

Exercice reproductible : comparer sept verdicts et quatre défauts

Le script Python de l’exercice R3 contient les sept données et leurs verdicts explicites. Il vérifie une implémentation minimale, puis les quatre variantes incorrectes. Les résultats attendus sont écrits dans le jeu de cas ; ils ne sont pas calculés en appelant une seconde fois la fonction évaluée.

Son périmètre est volontairement réduit : aucune base, aucun navigateur, aucun modèle d’IA et aucun système de paiement. Il ne prétend pas reproduire un moteur d’autorisation complet. On peut l’exécuter pour comprendre le raisonnement, puis construire des preuves adaptées au langage et à l’architecture du projet réel.

python3 oracle_approbation.py
7 cas conformes
4 défauts ciblés détectés : B, E, F, G

Le résultat attendu donne une information précise : les cas discriminent bien les quatre changements sélectionnés. Il ne donne pas un taux général de qualité du code. Si l’on ajoute une règle d’auto-approbation, une notion de délégation temporaire ou une autre devise, le petit programme reste insuffisant jusqu’à l’ajout des règles et cas correspondants.

Pour utiliser l’exercice en atelier, présentez d’abord le tableau aux métiers, sans montrer l’implémentation. Faites expliquer chaque verdict, puis comparez avec le programme. Un désaccord entre deux personnes doit produire un arbitrage de règle, pas une compétition pour deviner ce que le code actuel renvoie.

Passer de la fonction correcte aux droits réellement appliqués

Un test unitaire peut établir que la fonction refuse une autre société. Il ne prouve pas que le contrôleur HTTP l’appelle ni que l’identifiant de société vient d’une source fiable. L’application peut accepter un champ fourni par le navigateur et fabriquer elle-même les conditions qui rendent la fonction favorable.

Les recommandations OWASP sur l’autorisation demandent notamment un refus par défaut et la vérification des permissions à chaque requête. La présence ou l’absence d’un bouton ne remplace pas le contrôle sur le serveur. Ces principes guident la vérification des chemins qui atteignent réellement la décision.

Tester l’objet demandé avec le rôle ordinaire

Une recette HTTP doit utiliser un responsable de la société A et demander une opération sur un dossier de B. Elle vérifie le refus, l’absence de modification et l’absence de fuite de données. Répéter uniquement le parcours d’un administrateur ne couvre pas cette séparation.

Les exports, pièces jointes et tâches de fond peuvent emprunter d’autres chemins. Identifiez ceux qui portent la même règle et choisissez des contrôles adaptés. La couverture de l’endpoint principal ne permet pas de présumer que l’export applique automatiquement la restriction d’accès sur chaque dossier.

Relier le verdict à l’effet métier observé

Après une approbation, le statut doit être enregistré, l’auteur retrouvé et les effets nécessaires déclenchés. Une assertion qui observe seulement un message de succès peut manquer une transaction annulée ou une notification produite deux fois. Il faut suivre la décision jusqu’à l’effet qui donne son sens à l’usage.

Dans le scénario R3, une approbation n’effectue pas elle-même de remboursement. Elle autorise la suite du workflow fictif. La recette doit maintenir cette distinction pour éviter qu’un libellé « remboursé » apparaisse dès que le responsable clique. Le métier choisit les états utiles ; les tests vérifient leur enchaînement réel.

Éprouver une répétition et une interruption

Préparez deux appels portant sur la même demande déjà approuvée. Le résultat attendu doit préciser si la seconde action renvoie l’état existant ou un refus, et quels effets restent uniques. La règle de répétition doit être fixée avant d’observer ce que le serveur fait spontanément.

Interrompez ensuite un traitement dans un environnement de recette contrôlé et vérifiez sa reprise. La trace doit distinguer décision enregistrée, tâche en attente et effet confirmé. Si ces objets ne peuvent pas être rapprochés, le défaut appartient à l’architecture d’exécution ; il ne sera pas corrigé par davantage de tests sur la seule comparaison du montant.

Utiliser les outils de revue sans leur déléguer le verdict métier

La documentation GitHub sur la revue du code généré recommande de rapprocher contrôles fonctionnels, contexte, dépendances et revue collaborative. L’application card des agents Copilot rappelle aussi que la revue peut manquer des problèmes ou produire des faux positifs. Une suggestion automatique demande donc une vérification.

Un second modèle peut proposer des cas adverses utiles. Sa différence de nom ne rend toutefois pas son résultat indépendant par principe. Si on lui fournit le même résumé ambigu et qu’on lui demande seulement de valider le code, il peut reprendre la même hypothèse. Fournissez plutôt les règles acceptées et demandez des contre-exemples vérifiables.

Les outils d’analyse statique, de dépendances et de sécurité complètent cette revue. Le référentiel OWASP ASVS 5.0.0, publié le 30 mai 2025, organise des exigences de vérification de sécurité. Sélectionner des exigences applicables et conserver leurs preuves n’autorise pas à afficher une conformité globale sans évaluation correspondante.

Chaque outil doit produire une sortie exploitable : défaut reproductible, piste à qualifier ou absence de signal dans un périmètre défini. « Aucun problème trouvé » ne signifie pas que toutes les règles ont été comprises. La décision finale rapproche ces sorties au lieu de les additionner comme des votes équivalents.

Vérifier l’expérience utilisateur sans recopier le détail du code

Les bonnes pratiques Playwright recommandent de tester le comportement visible par l’utilisateur et d’isoler les tests. Cette approche aide à vérifier que le parcours expose correctement la décision, sans rendre les assertions dépendantes d’un nom de classe CSS ou d’une fonction interne.

Pour R3, le responsable doit comprendre pourquoi 1 000,01 euros demandent une validation complémentaire. Le formulaire doit afficher le montant exact, le statut obtenu et la prochaine action. Un test qui clique sur le premier bouton puis cherche seulement un message vert ne prouve pas cette compréhension.

La vérification visuelle examine également les petits écrans, le clavier, les erreurs de saisie et les informations masquées par un composant. Un montant tronqué ou un message de refus invisible peut rendre une règle backend correcte inutilisable. Conservez les contrôles utiles aux personnes qui effectueront réellement le travail.

Une capture n’est pas automatiquement une preuve de conformité. Avant d’approuver une image de référence, relisez les valeurs et l’état représentés. Sinon, les exécutions suivantes protégeront fidèlement une erreur initiale. La validation de la première référence mérite autant d’attention que les différences détectées ensuite.

Mise en œuvre : un dossier de preuve lié à la version livrée

Les entrées du dossier sont les règles versionnées, les données de recette, les rôles, le commit et la configuration évaluée. Les sorties rassemblent verdicts attendus, résultats observés, écarts et décisions d’ouverture. La responsabilité de la règle appartient aux métiers ; celle de la preuve technique est attribuée à une équipe capable de la reproduire.

La journalisation conserve les références nécessaires sans exposer de secrets ni de données personnelles inutiles. Le monitoring distingue échec de test, panne d’environnement et règle encore indécise. Les dépendances externes et les simulations sont signalées. Le repli précise quelles fonctionnalités restent fermées si une preuve critique manque.

• Une preuve locale porte sur la version et les données réellement utilisées.
• Une simulation de partenaire ne prouve pas ses droits ni sa configuration réelle.
• Une correction modifiant la règle impose de rejouer les cas concernés.
• Une livraison doit identifier l’artefact déployé, pas seulement le dernier code visible.

L’audit technique d’une application web peut rapprocher ces éléments lorsque le code, les tests et la démonstration racontent des histoires différentes. L’enjeu est d’obtenir un diagnostic exploitable : règle mal comprise, assertion faible, chemin non couvert ou environnement incomplet. Chacune de ces causes appelle un travail différent.

Appliquer cette séparation dans une application PHP/Symfony

La documentation Symfony sur les tests distingue unité, intégration et application. Pour une implémentation PHP de R3, la fonction de décision peut être vérifiée isolément, puis le backend testé avec sa vraie configuration de sécurité. Si Doctrine porte la persistance, contrôlez aussi le statut réellement enregistré. Le frontend doit enfin présenter la même décision, que l’action passe par un formulaire ou une API ; aucun de ces niveaux ne prouve automatiquement les autres.

Si une notification est confiée à Messenger, vérifiez le passage par le transport et le worker choisi, puis l’effet attendu après reprise. Une exécution synchrone de test ne reproduit pas à elle seule cette attente. La CI doit conserver la configuration évaluée et la version des dépendances Composer. Enfin, un cache de permissions peut maintenir un ancien droit : ajoutez un cas de changement d’habilitation et vérifiez le comportement du parcours après sa prise d’effet.

Erreurs fréquentes dans la réception de code généré

Changer l’attendu pour faire disparaître un échec

Un assistant peut proposer de mettre à jour le test parce que le comportement actuel diffère. Cette correction peut être légitime après un arbitrage métier ; elle peut aussi effacer le seul signal de régression. Exigez la référence du changement de règle avant d’accepter un nouvel attendu sur une décision importante.

Gardez séparés le correctif de production et la justification de recette. Le relecteur doit pouvoir expliquer pourquoi le nouveau résultat est juste sans utiliser l’argument « c’est ce que renvoie maintenant le code ». Si cette explication manque, le dossier reste ouvert même lorsque toute la suite redevient verte.

Remplacer les dépendances jusqu’à faire réussir le parcours

Une simulation qui retourne toujours « succès » rend le développement pratique, mais peut cacher un refus, un délai dépassé ou un format incompatible. Elle doit avoir un contrat et des limites explicites. Les cas critiques doivent inclure les erreurs attendues et les contrôles d’intégration nécessaires au parcours réel.

Évitez aussi les données artificiellement parfaites : tous les utilisateurs administrateurs, tous les dossiers complets et tous les partenaires disponibles. Ces choix fabriquent une démonstration favorable. Ils ne permettent pas de recevoir une application destinée à des rôles ordinaires, des documents incomplets et des opérations interrompues.

Pour qui cette vérification est utile : arbitrer la réception

Cette méthode concerne une équipe qui reçoit rapidement du code et des tests, sans savoir d’où viennent les résultats attendus. Elle s’applique à un prototype assisté par IA, à une reprise de projet ou à une évolution importante d’un logiciel existant. Elle n’exige pas de réécrire tout le produit avant de recevoir un premier usage.

• À faire : choisir une décision critique, écrire ses résultats attendus indépendants et provoquer un défaut qui doit être détecté.
• À différer : l’extension à de nouveaux rôles ou workflows tant que leurs règles ne sont pas arbitrées.
• À refuser : une ouverture fondée uniquement sur le nombre de tests, une couverture élevée ou l’approbation automatique d’un outil.

Le seuil d’arrêt dépend du dommage possible. Dans R3, une approbation étrangère à la société de l’acteur bloque le parcours concerné. Un libellé secondaire peut faire l’objet d’une réserve datée. Le verdict doit préciser la version, la population et les conditions admises, sans transformer une correction cosmétique en preuve sur les droits.

Plan d’action : recevoir une règle avant d’élargir l’application

Établir une référence et éprouver les tests existants

Commencez par choisir une décision dont une erreur aurait un coût concret : approbation, émission de document, changement de droit ou engagement externe. Rassemblez la règle utilisée par les métiers et les exemples déjà disponibles. Si deux personnes ne donnent pas le même verdict sur une limite, organisez l’arbitrage avant de demander une nouvelle génération de tests.

Écrivez ensuite un petit tableau de résultats attendus sans consulter la fonction. Incluez le nominal, la borne, un cas interdit et un état incomplet. Faites relire ce tableau par le propriétaire de la règle. Les valeurs doivent être explicables ; elles ne doivent pas provenir d’une exécution enregistrée puis acceptée par défaut.

Comparez les cas au code et à la suite existante. Identifiez les assertions qui calculent leur propre attendu, les préparations qui donnent trop de droits et les simulations qui évitent l’erreur. Introduisez quelques défauts ciblés dans une copie isolée et observez quels tests les détectent. Corrigez les preuves faibles avant d’augmenter leur nombre.

Vérifier l’assemblage et préparer le verdict de livraison

Passez ensuite aux chemins HTTP, à la persistance et aux tâches nécessaires. Utilisez les rôles ordinaires et des dossiers séparés. Vérifiez l’effet final après une répétition et une interruption, avec une trace que le support peut retrouver. Les simulations restent acceptables dans leur périmètre, à condition de compléter les points de raccordement réellement critiques.

Recevez le parcours visible sur ordinateur et mobile. Faites expliquer le statut et la prochaine action par une personne qui n’a pas construit l’application. Une incompréhension répétée devient un défaut du produit, même si la fonction métier renvoie la valeur attendue. Documentez les réserves avec leur conséquence, leur responsable et leur date de réexamen.

Terminez par un verdict rattaché à un artefact précis. Le décideur choisit ouvrir, limiter ou différer, avec les preuves et les inconnues correspondantes. Une nouvelle modification du droit, du calcul ou de l’environnement réactive les vérifications affectées. L’équipe peut alors élargir progressivement le périmètre sans perdre la relation entre règle, test et version réellement exploitée.

Guides complémentaires : de la preuve locale au premier usage reçu

Le dossier sur le contrôle d’acceptation d’une application métier explique comment réunir décision, droits, données et reprise avant l’ouverture. Il prolonge la preuve indépendante par une responsabilité de réception partagée entre métiers, produit et exploitation.

Lorsque la suite devient difficile à utiliser, la méthode sur les tests lents et peu pertinents aide à reconstruire le retour utile sans multiplier les parcours. Pour un logiciel dont la livraison reste incertaine, la reprise d’un projet web inachevé replace les preuves dans le choix entre finition, réduction du périmètre et reconstruction.

Conclusion : vérifier la règle que les tests prétendent protéger

Une suite verte indique que les assertions exécutées n’ont pas détecté de différence avec leurs attentes. La valeur de cette information dépend de la qualité et de l’indépendance de ces attentes. Quand le code et ses tests partagent une hypothèse erronée, leur cohérence peut renforcer une confiance injustifiée.

L’exercice R3 rend cette limite concrète : sept cas distinguent le seuil, le rôle, la société, l’état et la validité du montant. Quatre défauts volontaires éprouvent leur capacité de détection. Cette preuve ciblée reste modeste ; elle devient utile lorsqu’elle est reliée aux vrais chemins d’accès et aux effets du logiciel.

La bonne réception demande de rapprocher règle acceptée, comportement observé et version livrée. L’IA peut accélérer la préparation, proposer des variantes et aider à diagnostiquer. Les décisions métier et les limites de la preuve doivent rester identifiables, quelle que soit la manière dont le code a été produit. Un audit technique des preuves de votre application permet de choisir les règles à éprouver avant de réceptionner du code assisté par IA.

Dawap accompagne le développement et la reprise de vos applications métier avec cette exigence de résultat vérifiable. Le point de départ est un usage et ses décisions, puis les preuves nécessaires pour l’ouvrir. Le volume de code ou de tests ne remplace pas cette démonstration.