Correctif généré par IA : quelles preuves avant le merge ?

Un correctif généré par IA peut compiler, passer quelques tests et rester difficile à défendre en revue. Le point faible n’est pas toujours le code produit : c’est parfois l’absence de preuve permettant de relier le diff au comportement attendu.

Pour une équipe de développement, la question devient alors opérationnelle : faut-il s’appuyer sur une analyse statique, une suite de tests, une fixture comportementale ou une revue humaine structurée ? Ces dispositifs ne répondent pas au même risque et ne doivent pas être empilés par réflexe. Les recommandations de vérification logicielle du NIST distinguent elles aussi plusieurs techniques, dont les tests automatisés, l’analyse statique, les cas de test fonctionnels et la revue de code.

Le problème : un résultat vert ne constitue pas une preuve complète

Une vérification peut confirmer qu’un programme respecte une règle syntaxique, qu’un scénario connu fonctionne ou qu’un diff reste lisible. Elle ne démontre pas nécessairement que le correctif répond au besoin initial, qu’il ne modifie pas un comportement voisin ou qu’il restera compréhensible lors d’une prochaine évolution.

Le cas suivant est volontairement hypothétique : un agent reçoit un ticket demandant de refuser une valeur invalide dans une API. Le test nominal passe. Pourtant, la validation accepte encore une variante mal formée parce que le jeu de cas ne couvre pas cette frontière. Le problème n’est pas que le test est faux ; c’est qu’il ne couvre qu’une partie de la décision.

Quatre dispositifs à comparer

La comparaison ne désigne pas un vainqueur universel. L’analyse statique est peu coûteuse mais étroite. Les tests donnent une preuve exécutable, à condition que les cas soient pertinents. La fixture rend le comportement visible sur un exemple maîtrisé. La revue humaine apporte le contexte qui manque aux automatismes, mais elle devient fragile lorsqu’elle repose sur une impression générale. Les contrôles d’un fournisseur peuvent d’ailleurs combiner analyse déterministe, analyse par modèle, tests automatisés et validation humaine sans transformer une suggestion en changement accepté par défaut. La documentation GitHub sur ses fonctions de sécurité et de qualité assistées par IA décrit précisément cette séparation entre suggestion, vérification et acceptation.

Une chronologie de validation qui évite le contrôle en fin de parcours

1. Avant la génération : écrire le comportement attendu, les entrées refusées et les invariants qui ne doivent pas changer.
2. Après le premier diff : vérifier le périmètre, les fichiers touchés et les dépendances ajoutées avant d’exécuter une batterie complète.
3. Après les contrôles rapides : lancer l’analyse statique puis les tests ciblés, en conservant leurs sorties plutôt qu’un simple statut vert.
4. Avant la revue finale : exécuter une fixture comportementale qui représente le cas du ticket et au moins une frontière plausible.
5. Au moment de décider : demander une revue humaine focalisée sur les écarts entre le contrat initial, le diff et les preuves produites.

Cette séquence réduit un risque fréquent : demander à l’IA de produire le code, puis demander aux mêmes signaux généraux de confirmer que le code est bon. Chaque étape doit répondre à une question différente.

Quelle combinaison choisir selon le correctif ?

Pour cadrer un agent avant même la production du diff, l’arbre de décision avant délégation aide à distinguer une tâche vérifiable d’un ticket qui doit rester en binôme humain. Une fois le changement proposé, la méthode de code review avec l’IA apporte un cadre complémentaire pour formuler les contrôles, sans remplacer les preuves d’exécution.

Ce que cette méthode ne permet pas d’affirmer

Cette grille ne mesure ni la performance d’un outil particulier ni un taux de réussite universel. Elle ne constitue pas un benchmark exécuté : aucun modèle, dépôt, commit ou jeu de données précis n’est fourni ici. Elle sert à préparer un protocole d’évaluation local, reproductible et proportionné au risque.

Une équipe peut commencer avec un seul correctif synthétique, conserver le diff initial, les sorties brutes des contrôles et les cas de test, puis répéter la séquence avec une tâche différente. Le résultat utile n’est pas une note globale attribuée à l’IA, mais une décision documentée sur le niveau de preuve nécessaire pour chaque classe de changement.

Le choix pragmatique

Pour un changement local et réversible, l’analyse statique et les tests existants peuvent suffire à ouvrir une revue normale. Dès qu’un correctif modifie une règle métier, une interface ou un comportement transversal, il faut ajouter une fixture explicite et une revue centrée sur les écarts entre intention et implémentation.

La qualité du code généré ne se juge donc pas seulement à la plausibilité du diff. Elle se juge à la capacité de l’équipe à expliquer ce qui a été vérifié, ce qui ne l’a pas été et pourquoi la preuve obtenue est suffisante pour la décision prise.

Question de la rédaction : dans votre équipe, quelle preuve vous manque le plus souvent avant d’accepter un correctif généré par IA ?