Coder avec un assistant IA : méthode et garde-fous

En quelques années, les assistants de code sont passés de l'autocomplétion améliorée à des agents capables de lire un projet, modifier plusieurs fichiers et lancer les tests. Utilisés sans méthode, ils produisent vite du code qui « a l'air juste » mais que personne ne comprend. Utilisés avec méthode, ils font gagner un temps considérable.

Voici la façon de travailler que j'ai adoptée au quotidien.

Le principe : l'IA propose, le développeur dispose

L'assistant est un collaborateur très rapide, qui a beaucoup lu mais qui ne connaît ni votre produit, ni vos contraintes, ni l'historique de vos décisions. La responsabilité du code fusionné reste entièrement la vôtre. Tout le reste découle de ce principe.

1. Donner du contexte

La qualité de la réponse dépend directement de la qualité du contexte. Un bon point de départ :

• Un fichier d'instructions dans le dépôt (conventions, commandes de build et de test, architecture, choses à ne pas faire). La plupart des outils le lisent automatiquement.
• Des exemples existants : « fais comme dans UserService » vaut mieux qu'une longue description.
• Le résultat attendu et les contraintes : version des librairies, compatibilité, performance.

2. Planifier avant de générer

Pour toute tâche de plus de quelques lignes, je demande d'abord un plan : quels fichiers seront modifiés, quelle approche, quelles alternatives. Relire un plan de dix lignes prend une minute ; relire 500 lignes de code dans la mauvaise direction en prend trente.

3. Avancer par petits pas

• Un changement cohérent à la fois, qu'on peut relire en entier.
• Un commit par étape validée : si l'étape suivante part dans le mauvais sens, on revient en arrière sans rien perdre.
• Pas de « refais tout le module » : les grandes modifications d'un coup sont les plus difficiles à vérifier.

4. Relire comme une pull request

Le code généré mérite la même exigence que celui d'un collègue, voire plus. Les points que je vérifie systématiquement :

• Les API inventées : une méthode ou une option qui n'existe pas dans la version utilisée.
• La gestion des erreurs : les cas limites sont souvent traités de façon optimiste.
• La sécurité : requêtes SQL construites par concaténation, secrets en dur, validation des entrées absente.
• La duplication : l'assistant réécrit volontiers une fonction qui existe déjà ailleurs dans le projet.
• Les tests qui passent pour de mauvaises raisons : un test modifié pour correspondre au code, plutôt que l'inverse.

5. Les tests comme filet de sécurité

Les tests transforment l'assistant d'un générateur de code plausible en générateur de code vérifié. Une approche efficace : écrire (ou faire écrire et relire) les tests d'abord, puis demander l'implémentation jusqu'à ce qu'ils passent.

Prompt : « Voici le test qui échoue (formatPrice.test.ts).
Implémente formatPrice dans src/lib/format.ts pour le faire passer,
sans modifier le test. Utilise Intl.NumberFormat. »

Là où l'IA excelle… et là où elle est risquée

• Excellent : code répétitif, tests, scripts, migrations mécaniques, explication de code inconnu, première ébauche de documentation.
• Utile avec vigilance : refactorings, nouvelles fonctionnalités dans un code bien structuré.
• Risqué : sécurité, cryptographie, logique métier critique, choix d'architecture. L'IA peut aider à réfléchir, pas décider à votre place.

Et la confidentialité ?

Avant d'utiliser un assistant sur un projet client, vérifiez la politique de l'entreprise : quel outil est autorisé, les données sont-elles utilisées pour l'entraînement, où sont-elles hébergées. Ne collez jamais de secrets ni de données personnelles dans une conversation.

Conclusion

Les assistants IA ne remplacent pas le jugement du développeur, ils le rendent plus important que jamais. Contexte clair, plan d'abord, petites itérations, relecture sérieuse et tests : avec cette discipline, l'IA devient un vrai multiplicateur de productivité plutôt qu'une source de dette technique.