Assistants de code : bien cadrer une tâche

Un développeur indépendant demande à son assistant de code : « Ajoute un export CSV des factures. » Vingt minutes plus tard, l'outil a touché onze fichiers, ajouté une bibliothèque, reformaté deux modules qui n'avaient rien à voir et écrit un export qui oublie les avoirs. Rien n'est cassé de façon visible, et pourtant il faut tout relire.

Les assistants de code actuels ne se contentent plus de compléter une ligne. Ils lisent le projet, modifient plusieurs fichiers, lancent des commandes et des tests. Plus l'outil agit seul, plus ta demande doit ressembler à un brief qu'on donne à un prestataire qu'on ne verra pas avant la livraison.

Ce qu'un brief de tâche contient

Cinq éléments suffisent dans la plupart des cas.

1. L'objectif, dit en termes de résultat : ce que l'utilisateur ou le système pourra faire après.
2. Le périmètre : les fichiers ou dossiers concernés, et ce qu'il ne faut pas toucher.
3. Les contraintes : technologies imposées, conventions, dépendances interdites.
4. Le critère de réussite : comment tu sauras que c'est fini, de préférence une commande ou un test.
5. La façon de travailler : proposer un plan avant de modifier, ou avancer par petites étapes.

Voici le brief du développeur, repris proprement :

Objectif : ajouter un export CSV des factures d'un mois donné, accessible depuis la page Facturation.

Périmètre : tu peux modifier le module facturation/ et la page Facturation. Ne touche pas aux autres modules ni à la configuration du projet.

Contraintes : pas de nouvelle dépendance, on utilise le module CSV de la bibliothèque standard. Même style que les exports existants (voir export_clients).

Règles métier : l'export contient les factures et les avoirs du mois. Les avoirs sont en négatif. Les montants sont en centimes dans la base et en euros avec deux décimales dans le fichier.

Critère de réussite : les tests existants passent, et tu ajoutes un test qui vérifie un mois contenant une facture et un avoir.

Avant de modifier quoi que ce soit, décris-moi ton plan en cinq lignes maximum et attends mon accord.

La dernière phrase est la plus rentable. Un plan faux se corrige en dix secondes ; du code faux se corrige en dix minutes.

Ce que l'outil ne peut pas deviner

Les règles métier ne sont écrites nulle part dans le code, ou alors de façon indirecte. Le fait que les avoirs entrent dans l'export, que les montants soient en centimes, que la page s'appelle Facturation : l'assistant peut en retrouver une partie en lisant le projet, mais tu as plus vite fait de les écrire. Il vaut mieux dire une chose évidente de trop que d'obtenir un export faux et plausible.

Tout ce que tu répètes d'une tâche à l'autre (conventions, commandes de test, dossiers à éviter) peut aller dans un fichier d'instructions lu automatiquement par l'outil. Le nom du fichier et son emplacement dépendent de l'assistant que tu utilises. L'article sur les instructions pour agents IA explique comment le rédiger sans en faire un roman.

Un changement à la fois

La tentation, quand l'outil est rapide, est d'empiler les demandes : l'export, puis un filtre, puis une refonte de la page, le tout dans la même session. Chaque ajout rend le résultat plus difficile à relire. Prends l'habitude de découper, comme pour une chaîne de prompts :

• une tâche, un objectif, un résultat vérifiable ;
• une sauvegarde de ton travail (un commit) avant chaque tâche, pour pouvoir revenir en arrière ;
• une session neuve quand le sujet change, parce que la conversation s'alourdit et que l'outil finit par perdre des détails du début.

Si la tâche est trop grosse pour un brief d'une page, demande d'abord une découpe :

Je veux migrer l'authentification de l'application vers [NOUVELLE MÉTHODE]. Ne modifie rien pour l'instant. Parcours le projet, liste les fichiers concernés et propose un découpage en étapes indépendantes, chacune testable seule. Pour chaque étape, indique le risque principal.

Tu choisis ensuite l'étape à lancer et tu écris son brief.

Relire le résultat

Le travail ne s'arrête pas quand l'outil dit « terminé ». Quatre contrôles, dans cet ordre.

Le diff d'abord. Regarde la liste des fichiers modifiés avant d'ouvrir un seul fichier. Si elle contient des fichiers hors périmètre, demande pourquoi, ou annule.

Les tests ensuite, lancés par toi si possible. Un assistant peut affirmer que les tests passent sans les avoir exécutés correctement, ou modifier un test pour le faire passer. Vérifie que les tests existants n'ont pas été changés sans raison.

Les cas limites. Reprends les règles métier de ton brief et teste-les à la main : le mois sans facture, l'avoir plus grand que la facture, la valeur à zéro.

Les ajouts discrets. Dépendance nouvelle, fichier de configuration, suppression d'un bout de code qu'il jugeait inutile : demande à l'outil de les lister s'il ne l'a pas fait.

Résume ce que tu as modifié, fichier par fichier, en une ligne chacun. Indique ce que tu as supprimé, ajouté comme dépendance ou changé en dehors du périmètre demandé. Liste ensuite les cas limites que tu n'as pas testés.

Ce résumé ne remplace pas ta relecture du diff, car l'outil peut oublier de mentionner une modification. Il t'indique simplement où regarder.

Quand ça ne marche pas

Si l'assistant tourne en rond, corrige la cause plutôt que de répéter la demande. Souvent, c'est un contexte manquant ou une consigne contradictoire dans le brief. Repars d'une session neuve avec un brief corrigé, plutôt que d'ajouter « non, pas comme ça » vingt fois. Pour les tâches de relecture, de débogage ou de génération de tests en dehors de ce cadre, l'article sur les prompts pour développeurs donne d'autres modèles, et celui sur GitHub Copilot détaille le travail dans l'éditeur.

Et garde la main sur ce que l'outil peut faire : lancer des commandes, supprimer des fichiers, accéder au réseau. Lis ce que ton assistant te demande d'autoriser avant d'accepter, et évite de lui ouvrir un accès à des clés ou à des bases de production pour une tâche qui n'en a pas besoin.

À faire avant ta prochaine tâche

Prends une tâche que tu vas confier à l'assistant cette semaine. Écris les cinq lignes du brief, dont la commande qui prouvera que c'est fini. Si tu ne sais pas écrire cette commande, la tâche n'est pas encore assez claire, et c'est le moment de le découvrir.