Vérifier une réponse d'IA et le code généré

Vérifier une réponse d'IA, c'est retrouver chaque fait qui compte dans une source primaire et tester chaque morceau de code avant de l'adopter. La règle tient en une phrase : l'IA propose, la source et le test décident. Ce chapitre te donne la méthode, les sources à consulter, la façon de relire et de tester du code généré, et une checklist à garder sous la main.

Ce qui se vérifie toujours

Tout ne mérite pas une vérification : une reformulation de ton propre texte ou une liste d'idées se jugent à la lecture. En revanche, vérifie systématiquement :

• les chiffres, dates et numéros de version ;
• les noms exacts de commandes, d'options, de fonctions, de paramètres et de paquets ;
• les références : identifiant CVE, article de loi, norme, guide, URL ;
• les citations attribuées à une personne ou à un document ;
• tout code que tu vas exécuter, intégrer ou montrer.

Les sources primaires

Une source primaire est celle qui fait autorité sur l'information : l'éditeur pour son logiciel, le législateur pour la loi. Un blog ou un forum peut te mettre sur la piste, pas trancher.

Le cours Veille technologique détaille comment juger la fiabilité d'une source et recouper une information.

La méthode en quatre temps

1. Repérer les affirmations vérifiables de la réponse. Surligne-les mentalement : « l'option -Recurse », « depuis la version 8.4 », « l'article 32 du RGPD ».
2. Ouvrir la source. Pas la page citée par l'assistant sans la lire : la page elle-même, et le passage précis. Une source qui existe peut dire autre chose que ce que la réponse lui fait dire.
3. Tester ce qui se teste : la commande dans une VM, la requête sur une base de test, le code avec ses tests.
4. Décider : tu gardes, tu corriges ou tu écartes. Dans ta note ou ton code, cite la source primaire, pas l'assistant.

Relire du code généré

Un code généré se relit comme le code d'un collègue que tu ne connais pas, avec un soupçon de plus : il a l'air propre même quand il est faux. Pose-toi ces questions, dans l'ordre.

1. Est-ce que je comprends chaque ligne ? Si non, demande l'explication de la ligne, puis vérifie-la dans la documentation. Tu ne livres pas une ligne que tu ne saurais pas expliquer à l'oral de l'E6.
2. Fait-il ce qui était demandé, et seulement cela ? Un code généré ajoute parfois une fonction, modifie un comportement voisin ou supprime une vérification « pour simplifier ».
3. Que se passe-t-il dans les cas limites ? Une liste vide, une valeur NULL, un fichier absent, un accent dans un nom, une coupure réseau.
4. Les erreurs sont-elles traitées ? Méfie-toi d'un try qui avale toutes les exceptions sans rien dire.
5. Est-il sûr ? Voir la section suivante.
6. Les dépendances existent-elles, et sont-elles saines ? Voir les paquets inventés.

Le TP Coder avec l'IA : Claude & Artifacts te fait relire le HTML et le CSS produits par un assistant et y repérer les erreurs.

Tester avant d'adopter

• Dans un environnement de test : une VM avec un instantané, une base de test, une branche Git. Jamais directement en production.
• Avec des tests automatisés : écris toi-même au moins un test du cas nominal et un test d'un cas limite avant de demander le code, puis fais-les passer. Le cours Tests montre comment.
• À blanc d'abord pour un script d'administration : -WhatIf en PowerShell, une option --dry-run quand elle existe, ou un echo devant les commandes destructrices.
• Avec le moins de droits possible : n'exécute jamais en administrateur un script que tu n'as pas lu.

Les failles du code généré

Le code généré n'est pas sûr par défaut. En octobre 2026, l'éditeur Veracode a fait écrire du code à 18 modèles sur des tâches de test, en Python, C#, JavaScript et Java : 38 % du code produit contenait encore une faille, et sur les tâches exposées au XSS, seulement 18 % du code était protégé. Les failles qui reviennent le plus :

Les paquets inventés

Un assistant peut proposer d'installer une bibliothèque qui n'existe pas : le nom est plausible, il ressemble à de vrais paquets. Des chercheurs ont mesuré le phénomène sur 576 000 exemples de code Python et JavaScript générés par 16 modèles (Spracklen et al., USENIX Security 2025) : en moyenne, au moins 5,2 % des paquets cités par les modèles commerciaux n'existaient pas, et 21,7 % pour les modèles ouverts testés, soit 205 474 noms de paquets inventés différents. Comme les mêmes noms inventés reviennent d'une requête à l'autre, un attaquant peut publier un paquet malveillant sous l'un de ces noms et attendre que quelqu'un l'installe : on parle de slopsquatting.

Avant d'installer un paquet proposé par une IA :

1. cherche-le sur le registre officiel (npmjs.com, pypi.org, packagist.org) et vérifie que le nom est exactement le même ;
2. regarde l'éditeur, la date de création, le nombre de téléchargements et le dépôt de code associé : un paquet créé la semaine dernière, sans dépôt, n'inspire pas confiance ;
3. préfère la bibliothèque recommandée par la documentation officielle du langage ou du framework ;
4. verrouille les versions (package-lock.json, composer.lock) et fais analyser tes dépendances (chaîne d'approvisionnement).

Licences et provenance du code

Un modèle a appris sur du code public, dont une partie est sous licence. Il peut reproduire un extrait existant presque mot pour mot, sans en indiquer l'origine ni la licence. Certains outils signalent ces correspondances ; quand c'est le cas, lis la licence avant de garder l'extrait (licences logicielles). Pour ton portfolio, indique ce qui a été écrit avec une IA : le chapitre 13 y revient.

La checklist

Exercices

import mysql.connector

def tickets_du_demandeur(nom):
    cnx = mysql.connector.connect(host="192.168.10.179", user="root",
                                  password="Sorbier2026!", database="parc")
    cur = cnx.cursor()
    cur.execute(f"SELECT t.id_ticket, t.titre FROM ticket t "
                f"JOIN employe e ON e.id_employe = t.id_demandeur "
                f"WHERE e.nom = '{nom}'")
    try:
        return cur.fetchall()
    except:
        pass

import os
import mysql.connector

def tickets_du_demandeur(nom):
    cnx = mysql.connector.connect(
        host=os.environ["PARC_DB_HOST"],
        user=os.environ["PARC_DB_USER"],          # compte applicatif en lecture seule
        password=os.environ["PARC_DB_PASSWORD"],
        database="parc",
    )
    try:
        cur = cnx.cursor()
        cur.execute(
            "SELECT t.id_ticket, t.titre FROM ticket t "
            "JOIN employe e ON e.id_employe = t.id_demandeur "
            "WHERE e.nom = %s",
            (nom,),
        )
        return cur.fetchall()
    finally:
        cnx.close()