Coder avec l'IA : des workflows qui réduisent les risques

Règles pour une aide au code sans danger

La meilleure façon de coder avec l'IA est de la ralentir précisément là où deviner devient dangereux. L'IA sait expliquer du code inconnu, transformer une erreur en hypothèses, rédiger des tests, relire un diff et proposer des refactorisations. Elle sait aussi inventer des API, passer à côté de dépendances cachées, surinterpréter l'extrait que vous avez collé ou produire un correctif propre en apparence qui modifie un comportement que vous vouliez préserver.

Retenez cette règle : l'IA propose, votre dépôt décide. La source de vérité, c'est le code, la reproduction qui échoue, la suite de tests, les logs d'exécution, les exigences produit et la relecture humaine. Un bon binôme IA doit vous aider à raisonner à partir de ces éléments, pas les remplacer.

Règle	Pourquoi c'est important	Ce qu'il faut demander au modèle
Reproduire d'abord	Évite les correctifs au hasard	« Reformule le comportement défaillant et les preuves avant de proposer du code. »
Garder un périmètre étroit	Réduit le risque de régression	« Propose le plus petit changement sûr et liste les fichiers touchés. »
Préserver le comportement	Protège les utilisateurs et les contrats	« Nomme les invariants que ce changement ne doit pas casser. »
Exiger des tests	Rend la réponse vérifiable	« Écris des tests qui échouent avant le correctif et passent après. »
Relire avant de fusionner	Attrape les erreurs assurées	« Relis ce diff pour la justesse, la sécurité et les cas limites oubliés. »

Cela vaut pour tous les modèles. OpenAI, Anthropic et d'autres fournisseurs publient une documentation qui décrit des capacités, des fenêtres de contexte et des usages d'outils différents. Ces capacités sont utiles, mais elles ne remplacent pas un workflow discipliné. Pour du travail d'ingénierie, jugez les modèles avec la même exigence que pour un collègue : demandent-ils le contexte qui manque, réduisent-ils l'incertitude, respectent-ils les contraintes et laissent-ils une trace que vous pouvez vérifier ?

Workflow de débogage

Un workflow de débogage fiable avec l'IA comporte cinq phases : reproduire, isoler, formuler des hypothèses, corriger et vérifier. Ne commencez pas par « corrige ça ». Commencez par les preuves. Donnez au modèle la commande qui échoue, l'erreur exacte, le comportement attendu, le comportement observé, le code concerné, les détails de l'environnement et tout changement récent qui pourrait être en cause.

Phase 1 : capturez la reproduction. Pour du code backend, incluez la requête, la réponse, le code de statut, les logs et le test qui échoue. Pour du code frontend, incluez la route, l'action utilisateur, l'erreur dans la console du navigateur, la réponse réseau, l'état du composant et la description d'une capture d'écran si c'est pertinent. Pour un problème de build, incluez la commande, le gestionnaire de paquets, la version de Node et l'erreur complète autour du premier échec.

Phase 2 : demandez des hypothèses avant du code. Un modèle rigoureux doit classer les causes probables et dire quelles preuves étayent chacune d'elles. S'il n'arrive pas à trancher entre plusieurs causes, demandez la plus petite étape de diagnostic possible. Ce sera peut-être un log, un test ciblé, une vérification de types ou la lecture d'un fichier de plus.

Phase 3 : demandez le plus petit correctif possible. Dites au modèle de ne pas renommer de variables, de ne pas réécrire le code alentour, de ne pas ajouter de dépendances et de ne pas modifier le comportement public sans pouvoir le justifier. Demandez-lui de renvoyer la cause racine, le plan du correctif, les fichiers touchés, les tests et le risque.

Phase 4 : lancez les tests en local. La sortie de l'IA n'est pas une étape de vérification. L'étape de vérification, c'est la commande ou le parcours utilisateur qui prouve le comportement. S'il n'existe aucun test automatisé, demandez d'abord au modèle de créer un test de non-régression, puis d'implémenter le correctif.

Prompt de débogage :

Agis comme un binôme de débogage rigoureux. N'écris pas encore de code. Reformule d'abord la reproduction, le comportement attendu, le comportement observé et les trois causes racines les plus probables. Classe chaque cause selon les preuves. Propose ensuite la plus petite étape de diagnostic. Bug : [décris]. Commande ou action utilisateur : [colle]. Erreur/logs : [colle]. Code concerné : [colle]. Contraintes : [stack, fichiers à ne pas toucher, comportement à préserver].

Prompt de correctif :

À partir de la cause racine confirmée, propose le plus petit correctif sûr. Renvoie : la cause racine, les fichiers/fonctions à modifier, le plan du correctif, les tests qui échouent avant et passent après, les cas limites et le risque en cas de retour arrière. Ne refactorise pas de code sans rapport. Contexte : [colle].

Workflow de revue de code

L'IA est souvent meilleure en relectrice qu'en première autrice. Quand vous lui demandez de relire un diff, elle peut chercher les cas limites oubliés, les problèmes de sécurité, les hypothèses périmées, les trous dans les tests et les changements de comportement. Tout l'enjeu est de rendre la revue précise. Si vous demandez « ça te paraît bien ? », vous récolterez une approbation polie. Si vous demandez le risque sur la justesse, vous avez bien plus de chances d'obtenir des objections utiles.

Donnez au modèle le diff, le comportement visé, les tests associés et les contraintes éventuelles. Demandez-lui d'ignorer le style mineur, sauf s'il nuit à la maintenabilité. Vous voulez une revue qui priorise les bugs, pas les remarques de pure forme.

Zone de revue	Questions auxquelles l'IA doit répondre
Justesse	Le diff satisfait-il vraiment le besoin ?
Risque de régression	Quel comportement existant pourrait changer par accident ?
Sécurité	Les entrées, l'authentification, les secrets, les permissions et les risques d'injection sont-ils traités ?
Gestion des erreurs	Que se passe-t-il en cas de valeur nulle, de timeout, de réessai, de réponse invalide ou d'état partiel ?
Tests	Quelles promesses de comportement ne sont pas couvertes ?
Maintenabilité	Le changement suit-il les usages du projet et reste-t-il compréhensible ?

Prompt de revue de code :

Relis ce diff comme un mainteneur exigeant mais pragmatique. Concentre-toi sur la justesse, le risque de régression, la sécurité, les cas limites et les tests manquants. Ignore le style mineur sauf s'il crée un vrai risque de maintenance. Renvoie un tableau avec le problème, la priorité, la preuve tirée du diff, le correctif suggéré et le test nécessaire. Comportement visé : [colle]. Diff : [colle]. Tests existants : [colle].

Pour les changements à fort risque, comparez les correctifs de plusieurs modèles dans Whizi. Lancez le même prompt de revue sur deux ou trois modèles. Si un modèle signale un problème possible, ne l'acceptez pas les yeux fermés : vérifiez qu'il est réel dans le code. Le but n'est pas de collectionner les avis. Le but est d'élargir la surface de revue avant de fusionner.

Workflow de refactorisation et de tests

Refactoriser avec l'IA est risqué, car beaucoup de refactorisations se jugent à ce qui ne change pas. Le modèle peut rendre le code plus joli tout en modifiant subtilement le comportement, la gestion des erreurs, le timing ou les contrats publics. Un workflow de refactorisation plus sûr commence par définir les invariants avant de toucher à l'implémentation.

Étape 1 : décrivez l'objectif de la refactorisation. Par exemple : réduire la duplication, découper un gros composant, isoler l'accès aux données, simplifier les branchements, migrer un wrapper d'API ou améliorer la testabilité. Énoncez ensuite ce qui doit rester identique : signatures des fonctions publiques, comportement des routes, noms d'événements, formes des réponses, analytics, permissions, comportement d'accessibilité et attentes de performance.

Étape 2 : demandez un plan par étapes. Un bon plan de refactorisation proposé par l'IA doit être réversible. Chaque étape doit toucher une petite zone, inclure des tests et produire un état intermédiaire fonctionnel. Évitez les réécritures d'un seul bloc, sauf si le code est minuscule et bien couvert.

Étape 3 : écrivez des tests de caractérisation. Avant de modifier le code, demandez à l'IA d'identifier le comportement actuel et de rédiger des tests qui verrouillent les cas importants. Ces tests sont particulièrement utiles sur du code legacy dont l'intention est floue. Ils doivent couvrir les entrées normales, les entrées limites, les chemins d'échec et un cas de non-régression lié à la raison de la refactorisation.

Étape 4 : implémentez une étape à la fois. Après chaque étape, lancez les tests et demandez une revue ciblée. Si le modèle propose une abstraction large, exigez qu'il prouve qu'elle supprime une vraie duplication ou un vrai risque. Sinon, gardez le code ennuyeux et local.

Prompt de plan de refactorisation :

Crée un plan de refactorisation par étapes. Objectif : [objectif]. Code actuel : [colle]. Contraintes : préserver le comportement public, limiter le volume de changements, suivre les usages existants, éviter les nouvelles dépendances, garder chaque étape testable. Renvoie : les invariants, la carte des dépendances, les étapes, les fichiers touchés, les tests par étape, le risque en cas de retour arrière et une liste de contrôle pour la revue.

Prompt de tests unitaires :

Écris les tests avant de modifier l'implémentation. Utilise le style de test existant montré ici : [colle]. Comportement à préserver : [colle]. Code à tester : [colle]. Renvoie les noms de tests, la mise en place, les entrées, le résultat attendu et l'intérêt de chaque test. Inclus le cas nominal, un cas limite, un cas d'erreur et un cas de non-régression.

Modèles de prompts

Les bons prompts de code ne sont pas longs par coquetterie. Ils sont juste assez longs pour lever l'ambiguïté. Le modèle a besoin d'un rôle, d'une tâche, d'un contexte, de contraintes, d'un format de sortie et de critères de vérification. Sauvegardez les prompts qui fonctionnent pour que l'IA devienne un workflow d'ingénierie reproductible plutôt qu'une conversation ponctuelle.

Prompt d'explication de code :

Explique ce code à un développeur qui rejoint le projet. Couvre l'objectif, les entrées, les sorties, le flux de données, les dépendances, les modes de défaillance et les tests qui augmenteraient la confiance. Sépare les faits visibles dans le code des hypothèses. Code : [colle].

Prompt de code sécurisé :

Relis ce code à la recherche de risques de sécurité. Concentre-toi sur l'authentification, les permissions, les injections, les secrets, la validation, les redirections non sûres, la gestion des fichiers, le risque lié aux dépendances et l'exposition de données sensibles. Ne renvoie que des problèmes avec preuve, impact, correctif suggéré et test ou vérification manuelle. Code/diff : [colle].

Prompt de comparaison entre modèles :

Je compare des modèles d'IA sur une tâche de code. Utilise uniquement le contexte fourni. Renvoie la cause racine, le plus petit correctif sûr, les tests, les risques, les hypothèses et les questions. Note ta confiance de 1 à 5 et liste les preuves qui changeraient ta réponse. Tâche : [colle]. Contexte : [colle].

Liste de contrôle avant d'accepter du code généré par l'IA :

• Le modèle a reformulé la tâche correctement.
• Le correctif est plus petit que le problème, pas plus gros.
• Le comportement public et les contrats sont nommés.
• Les tests couvrent directement le bug ou l'objectif de refactorisation.
• Les cas limites et les chemins d'échec sont listés.
• Les entrées sensibles pour la sécurité ont été relues.
• Le diff suit les usages existants du projet.
• Vous avez lancé le test, le lint, le build ou la reproduction manuelle qui s'imposait.
• Un humain a relu le diff final.

Whizi est utile quand vous voulez comparer des correctifs sans changer la tâche. Collez le même prompt de débogage ou de revue dans plusieurs modèles, puis notez les sorties selon les preuves, le périmètre, les tests et le risque. Commencez par les alternatives à ChatGPT pour le code si vous cherchez un guide de choix de modèle, comparez les formules sur la page tarifs, ou créez un compte pour lancer ce workflow sur votre propre code.