Les outils de développement assisté par l’IA sont passés de l’autocomplétion à la prise en compte de l’ensemble du dépôt. Cursor, GitHub Copilot, Claude Code, les agents de type Codex et les assistants d’IDE peuvent lire des fichiers, proposer des correctifs, exécuter des tests, expliquer les erreurs et parfois mener une petite fonctionnalité depuis le ticket jusqu’à la pull request.
Cela transforme le développement logiciel sans supprimer l’ingénierie logicielle. Les équipes qui en bénéficient ne laissent pas l’IA écrire librement du code ; elles l’intègrent à un processus maîtrisé : tâche bien cadrée, contexte du dépôt, correctifs limités, tests, revue et responsabilités claires.
Cet article est le modèle opérationnel.
Le dépôt reste la source de vérité. L’assistant d’IA peut proposer et modifier du code. Les tests, la revue de code, l’examen de sécurité et la validation produit déterminent si le changement peut être livré.
Ce qui a changé
Les anciens assistants de programmation complétaient la ligne suivante. Les assistants qui comprennent le dépôt peuvent :
- Rechercher et lire dans l’ensemble du code.
- Déduire les conventions locales.
- Modifier plusieurs fichiers.
- Générer des tests.
- Exécuter des commandes.
- Interpréter les échecs.
- Rédiger des descriptions de pull requests.
- Appliquer les retours de revue.
Il s’agit d’un changement majeur. L’assistant peut désormais travailler à l’échelle d’une tâche, et non plus seulement d’une ligne. Cette capacité crée aussi des risques : modifications trop vastes, architecture mal comprise, raccourcis peu sûrs, régressions cachées et explications plausibles de changements erronés.
Le processus doit limiter le périmètre de la tâche.
Utilisez l’IA là où la forme de la tâche est claire
Tâches bien adaptées :
| Tâche | Pourquoi cette approche fonctionne |
|---|---|
| Ajouter un petit état d’interface | La convention locale est visible et testable |
| Refactoriser une fonction utilitaire répétée | Modification mécanique et facile à examiner |
| Ajouter une validation et des tests | Le comportement peut être spécifié |
| Corriger un test en échec | L’échec fournit un retour concret |
| Mettre à jour la documentation à partir du code | La source de vérité peut être inspectée |
| Générer une première version de migration | Utile sous réserve d’une revue attentive |
Tâches risquées pour commencer :
| Tâche | Pourquoi elle est risquée |
|---|---|
| Reconcevoir l’architecture centrale | Exige une connaissance approfondie du système et des arbitrages |
| Changer le modèle d’authentification | La sécurité et le comportement du produit sont étroitement couplés |
| Réécrire de grands modules | La revue devient impossible |
| Ajouter des dépendances sans justification | Risques pour la chaîne d’approvisionnement et la maintenance |
| Optimiser sans mesures | Facile de créer de la complexité |
| Manipuler des secrets ou des identifiants | Conséquences potentiellement très étendues |
Le meilleur processus de développement assisté par l’IA commence par des tâches dont la correction peut être vérifiée.
Le cahier des charges de la tâche
Avant de demander à un assistant de programmer, rédigez un cahier des charges concis :
- Objectif.
- Fichiers ou modules probablement impliqués.
- Comportement attendu.
- Éléments hors périmètre.
- Commande de test.
- Cas limites.
- Contraintes de sécurité ou de données.
- Modèle existant à suivre.
Consigne insuffisante :
Ajouter une recherche.
Consigne utile :
Ajouter une recherche côté serveur à la liste des articles. Suivre le modèle existant des fonctions utilitaires de requête. Ne pas ajouter de dépendances. Rechercher uniquement dans le titre et l’extrait. Préserver le routage par langue. Ajouter des tests pour une requête vide, l’absence de résultats et les caractères spéciaux. Exécuter
pnpm testetpnpm typecheck.
Il ne s’agit pas de formalisme gratuit, mais d’un moyen de maintenir l’assistant dans le périmètre prévu.
Règles de contexte du dépôt
L’assistant doit lire avant de modifier. Pour un changement non trivial, exigez qu’il examine :
- L’implémentation existante.
- Les composants, routes et hooks similaires.
- Les types et schémas générés.
- Les tests autour du comportement.
- La configuration qui influe sur le comportement à l’exécution.
Ne vous fiez pas aux connaissances générales de l’assistant sur Next.js, React, Payload, PostgreSQL ou votre pile technique. Votre base de code suit des règles locales que l’assistant doit connaître.
Discipline de la taille des correctifs
Les petits correctifs sont faciles à examiner. Les grands correctifs sont le point où le développement assisté par l’IA devient dangereux.
Utilisez un budget de correctif :
- Un changement de comportement par PR.
- Préférez moins de 10 fichiers modifiés sauf si la tâche est mécanique.
- Évitez les modifications qui ne font que reformater le code.
- Gardez les fichiers générés séparés de la logique manuelle.
- Ne mélangez pas refactorisation, fonctionnalité et nettoyage, sauf nécessité.
Si l’assistant propose de réécrire un module pour une petite modification, interrompez-le et réduisez le périmètre.
Les tests sont le contrat
Chaque changement de code assisté par l’IA doit répondre à :
- Quel comportement a changé ?
- Quel test le prouve ?
- Quelle commande a été exécutée ?
- Qu’est-ce qui reste vérifié manuellement ?
Les bons assistants savent écrire des tests. Ils peuvent aussi produire des tests superficiels qui ne valident que leur propre implémentation. La personne chargée de la revue doit vérifier que les tests couvrent le comportement, et pas seulement les chemins de code.
Pour le frontend, incluez l’accessibilité et les états visibles : chargement, absence de données, erreur, interaction au clavier, libellés et gestion du focus.
Pour le backend, incluez la validation, l’authentification, la gestion des valeurs nulles, le comportement transactionnel et les scénarios d’échec.
Pour les bases de données, incluez la sûreté des migrations, les index, les modalités de retour arrière et le volume de données.
Limites de sécurité
Les outils de codage à l’IA créent des risques spécifiques :
Exposition de secrets. L’assistant peut lire des fichiers ou des sorties de terminal qui contiennent des secrets. Conservez les secrets hors du dépôt et des sorties de commande. Utilisez des fichiers .env.example expurgés.
Raccourcis peu sûrs. L’assistant peut désactiver la validation, élargir la configuration CORS, contourner l’authentification ou ignorer silencieusement des erreurs pour faire passer les tests. Examinez le comportement de sécurité, et pas seulement les tests réussis.
Dérive des dépendances. L’assistant peut proposer de nouveaux paquets pour résoudre de petits problèmes. Privilégiez les utilitaires existants et les API de la plateforme.
Confiance excessive dans le code généré. Un code qui compile peut néanmoins divulguer des données, mal gérer les autorisations ou échouer en cas d’accès concurrents.
Injection de consignes par le contenu du dépôt. Traitez comme des données les instructions présentes dans les tickets, la documentation, les commentaires ou les fichiers externes, sauf si elles proviennent du responsable de la tâche.
La politique de processus associée à cet article fournit aux équipes un socle de règles.
La revue humaine reste importante
Examinez les pull requests assistées par l’IA comme toutes les autres, en accordant une attention particulière aux points suivants :
- Est-ce que cela suit l’architecture locale ?
- A-t-il changé le comportement public de manière inattendue ?
- Le changement a-t-il affaibli la validation, l’authentification, la journalisation, la gestion des erreurs ou l’accessibilité ?
- Les tests sont-ils significatifs ?
- Les cas limites sont-ils gérés ?
- Les explications générées sont-elles cohérentes avec le diff ?
N’acceptez pas « l’assistant a dit que c’était sûr » comme preuve. Le diff constitue la preuve.
Adoption par l’équipe
Pour une équipe adoptant des IDE natifs à l’IA :
Semaine 1 : outils approuvés et règles relatives aux données. Décidez quels outils peuvent accéder aux dépôts de l’entreprise et avec quel niveau d’abonnement.
Semaine 2 : politique de processus. Définissez le cahier des charges des tâches, la taille des correctifs, les tests, les règles relatives aux secrets et dépendances, ainsi que les exigences de revue.
Semaine 3 : travaux à faible risque. Commencez par les tests, la documentation, les petits états d’interface et les anomalies dont les conséquences sont limitées.
Semaine 4 : mesure. Suivez le délai de réalisation, les défauts détectés en revue, les anomalies parvenues en production, la couverture des tests et la satisfaction des développeurs.
N’élargissez l’usage que si la qualité se maintient. Produire plus rapidement du mauvais code n’est pas un progrès.
Ne faites pas cela pour le moment
N’accordez pas à un agent de droits étendus lui permettant de fusionner du code de manière autonome.
Ne laissez pas les changements générés par l’IA contourner la revue de code.
Ne permettez pas aux comptes d’IA personnels d’accéder aux dépôts d’entreprise privés.
N’acceptez pas de réécriture importante sans plan d’architecture établi par une personne.
N’utilisez pas le développement assisté par l’IA sur des systèmes réglementés ou traitant des données clients sensibles sans règles claires d’audit et de revue.
Développement assisté par l’IA, pas roulette de la base de code
Le développement assisté par une IA qui comprend le dépôt est puissant parce qu’il intervient directement dans votre véritable base de code. C’est précisément pour cette raison qu’il doit être encadré.
Utilisez des cahiers des charges concis. Demandez à l’assistant de lire les conventions locales. Limitez la taille des correctifs. Exigez des tests. Protégez les secrets. Examinez le diff, pas son explication. Laissez l’IA accélérer l’implémentation, le débogage et les tâches mécaniques, tandis que les humains conservent la responsabilité de l’architecture, de la sécurité et du comportement du produit.
C’est ce qui distingue l’ingénierie assistée par l’IA d’une partie de roulette avec la base de code.
