Cinq erreurs avec les outils IA de code

Un assistant peut accélérer une modification, mais il ne connaît pas toutes les contraintes du projet. Les cinq erreurs ci-dessous compliquent surtout la revue et le retour en arrière. Pour le cycle de travail complet, consultez la définition et les limites du vibecoding.

1. Travailler sans Git

Sans historique, une modification ratée devient difficile à isoler. Initialisez un dépôt, vérifiez git status, puis créez un commit avant une série de changements. Demandez ensuite une modification à la fois et examinez le diff.

Git documente les commandes init, status, diff, commit et restore. GitHub rappelle qu’un système de gestion de versions conserve l’historique et permet de récupérer une version antérieure. Ces commandes sont données d’après la documentation ; elles n’ont pas été exécutées pour cette page.

2. Mettre des secrets dans le prompt ou le dépôt

Ne collez pas une clé API, un mot de passe ou un jeton dans une conversation. Ne les inscrivez pas non plus dans un fichier versionné. Utilisez une valeur fictive dans l’exemple et stockez le vrai secret dans la configuration protégée de l’environnement.

Si un secret a été exposé, retirez-le du service concerné et remplacez-le. Effacer la ligne du dernier commit ne suffit pas forcément, car la valeur peut rester dans l’historique ou dans des journaux. Le projet OWASP sur la sécurité de l’IA générative fournit un cadre pour examiner les risques des applications à base de LLM et des agents.

3. Accepter du code sans le vérifier

Demandez quel comportement a changé et quel test le couvre. Lancez les tests existants qui concernent ce comportement, puis ajoutez un cas de non-régression si le projet le permet. Essayez aussi le parcours et ses échecs attendus.

Un test qui passe ne valide que les assertions écrites. Il ne prouve pas que les permissions, les migrations, les paiements ou les sauvegardes sont corrects. Lisez le diff avant de fusionner le changement.

4. Écrire un prompt trop vague

« Améliore l’application » laisse l’outil choisir le périmètre. Indiquez le fichier ou la fonction, le comportement actuel, le résultat attendu, les contraintes et la vérification. Pour une modification large, demandez d’abord une proposition de plan et refusez les changements sans rapport.

Un bon critère se voit : « une adresse invalide affiche ce message sans requête réseau » se vérifie mieux que « rends le formulaire robuste ».

5. Refaire l’architecture à chaque bug

Une erreur de validation ne justifie pas forcément un changement de framework. Reproduisez le bug, gardez le message d’erreur, trouvez le plus petit correctif et ajoutez un test qui échouait auparavant. Si la correction demande une migration, examinez ses conséquences et préparez un retour arrière.

Changer plusieurs couches à la fois efface les indices utiles. Un correctif court n’est pas toujours le bon, mais il est plus simple à discuter et à annuler.

Ces habitudes ne rendent pas le code généré sûr par défaut. Elles rendent les changements visibles : un périmètre court, un historique, aucun secret dans le contexte et une vérification adaptée au risque. Aucun assistant ni aucune commande n’ont été testés dans le cadre de cette revue éditoriale.

Sources

Sources officielles consultées le 19 octobre 2026 :