Les assistants de programmation fondés sur l'intelligence artificielle font désormais partie du quotidien de nombreux développeurs, moi compris. Ils rédigent une fonction en quelques secondes, proposent des tests, expliquent un code inconnu ou convertissent un script d'un langage à l'autre. Mais le code généré par IA a une particularité trompeuse : il a toujours l'air correct. Il compile, il est bien présenté, il est accompagné d'explications assurées… et il peut pourtant contenir une faille de sécurité, une dépendance inventée ou une erreur de logique. Voici les relectures que j'applique systématiquement avant de livrer.
Pourquoi le code généré par IA demande une vigilance particulière
Un assistant IA produit le code le plus plausible compte tenu de sa demande et de son contexte. Plausible ne veut pas dire correct. Il ne connaît pas toujours vos contraintes métier, la version exacte de vos bibliothèques, ni les règles de sécurité propres à votre projet. Et il ne signale pas spontanément ce qu'il ignore.
Le risque principal n'est donc pas technique, mais humain : on relit moins attentivement un code qui semble propre et qu'on n'a pas écrit soi-même. La responsabilité, elle, ne change pas : le développeur qui livre le code en répond, qu'il l'ait tapé ou fait générer. Pour un tour d'horizon des outils, voir mon article sur l'IA générative dans le développement web.
Relecture n°1 : comprendre chaque ligne
La règle de base : ne jamais intégrer un code qu'on ne serait pas capable d'expliquer. Si une portion reste obscure, demandez à l'assistant de la détailler, consultez la documentation officielle, ou réécrivez-la plus simplement. Un code incompris est un code impossible à maintenir, et c'est souvent là que se cachent les erreurs.
Relecture n°2 : la sécurité
Les modèles reproduisent les motifs fréquents dans les codes qu'ils ont vus, y compris les mauvais. Les points à vérifier en priorité correspondent aux grandes familles de vulnérabilités du Top 10 de l'OWASP, que je détaille dans mon article sur la sécurité web :
- Les requêtes SQL : elles doivent utiliser des requêtes préparées, jamais une concaténation de variables ;
- L'affichage des données : tout ce qui vient d'un utilisateur doit être échappé, sous peine de faille XSS ;
- Les contrôles d'accès : vérifier que l'utilisateur a le droit d'agir sur la ressource demandée, pas seulement qu'il est connecté ;
- Les fichiers envoyés : type, taille, nom et dossier de destination contrôlés ;
- Les secrets : aucune clé d'API ni mot de passe écrit en dur dans le code (voir la gestion des secrets).
Voici un exemple typique de suggestion à corriger :
// Proposé tel quel : injection SQL possible
$rows = $pdo->query("SELECT * FROM orders WHERE customer_id = " . $_GET['id']);
// Corrigé : requête préparée et valeur typée
$statement = $pdo->prepare('SELECT * FROM orders WHERE customer_id = :id');
$statement->execute(['id' => (int) ($_GET['id'] ?? 0)]);
$rows = $statement->fetchAll();
Relecture n°3 : les dépendances et les API inventées
Les modèles de langage peuvent proposer une fonction qui n'existe pas, une option de configuration imaginaire ou un paquet au nom plausible mais inexistant. Ce dernier cas est dangereux : des attaquants publient précisément des paquets malveillants sous des noms que les IA ont tendance à inventer, une technique parfois appelée slopsquatting.
Avant d'installer une dépendance suggérée, vérifiez qu'elle existe réellement, qu'elle est maintenue, qu'elle est utilisée et qu'elle correspond bien à ce que vous cherchez. Lancez ensuite un audit des dépendances (composer audit, npm audit), comme expliqué dans mon article sur Composer.
Relecture n°4 : la compatibilité des versions
L'assistant peut mélanger des syntaxes de versions différentes : une fonction apparue dans PHP 8.4 dans un projet qui tourne en 8.2, une option de configuration supprimée d'une version récente de Symfony, un attribut obsolète. Comparez toujours avec la documentation de la version réellement utilisée. Les nouveautés récentes, comme l'opérateur pipe de PHP 8.5, sont justement celles que les modèles maîtrisent le moins bien.
Relecture n°5 : les tests
Un test automatisé ne ment pas. Faites tourner la suite de tests existante, et ajoutez des tests pour le code généré, en particulier pour les cas limites : valeur vide, tableau vide, caractères spéciaux, date en fin de mois. Vous pouvez demander à l'IA de proposer des tests, mais relisez-les aussi : un test qui vérifie le mauvais comportement donne une fausse assurance. Mon guide PHPUnit explique comment démarrer.
Relecture n°6 : la cohérence avec le projet
Un code peut être juste et pourtant mal intégré : conventions de nommage différentes, logique dupliquée alors qu'un service existe déjà, style incohérent avec le reste du projet. Ces écarts s'accumulent et rendent le projet difficile à maintenir. Un refactoring ponctuel coûte moins cher que de laisser la dette s'installer.
Relecture n°7 : la confidentialité de ce que vous partagez
La vigilance concerne aussi ce que l'on envoie à l'assistant. Ne copiez jamais dans un outil en ligne des données personnelles de clients, des fichiers de configuration contenant des secrets ou du code couvert par une clause de confidentialité. Vérifiez les conditions d'utilisation de l'outil et les options de non-réutilisation des données, surtout lorsque vous travaillez pour des clients.
Les outils qui aident à relire
Les relectures humaines s'appuient utilement sur des outils automatiques, branchés dans une chaîne d'intégration continue :
- L'analyse statique (PHPStan, Psalm, ESLint), qui détecte les types incohérents et les appels de fonctions inexistantes ;
- Les outils de formatage, qui imposent un style uniforme ;
- Les scanners de sécurité et l'audit des dépendances ;
- La revue de code par un pair, quand l'équipe le permet.
Mon usage au quotidien
J'utilise l'IA comme un assistant rapide pour les tâches répétitives, l'exploration d'une bibliothèque ou la rédaction d'une première version, jamais comme un pilote automatique. Le gain de temps est réel, à condition de réinvestir une partie de ce temps dans la relecture. C'est cette exigence qui garantit à mes clients un code sûr et maintenable, quelle que soit la façon dont il a été écrit. Si vous voulez faire relire un projet développé avec l'aide de l'IA, ou faire auditer son code, parlons-en.
