Comment bien utiliser GitHub Copilot?

GitHub Copilot, maintenant offert en aperçu technique sous forme d’extension pour Visual Studio Code, lit le code et les commentaires autour de votre curseur et propose la ligne suivante ou une fonction entière. Les développeurs qui en tirent de bons résultats font généralement deux choses différemment. Ils lui fournissent un meilleur contexte, et ils examinent ce qu’il produit avec le même soin qu’ils accorderaient à la demande de fusion (pull request) d’un inconnu.

Ces deux habitudes découlent du fonctionnement de l’outil. Copilot tourne sur Codex, un modèle d’OpenAI entraîné sur du code public qui prolonge la régularité qu’il voit, quelle qu’elle soit. Il n’a aucune idée de la raison d’être de votre projet. Tout ce qu’il sait de votre intention vient du texte du fichier que vous modifiez.

Donnez-lui un contexte qu’il peut utiliser

La FAQ de GitHub indique que Copilot fonctionne mieux quand le code est divisé en petites fonctions avec des noms de paramètres parlants, de bonnes docstrings et de bons commentaires. Ce conseil vaut la peine d’être pris au pied de la lettre :

• Nommez les choses selon leur sens. Une fonction appelée parse_invoice_total(text) en dit beaucoup plus au modèle que process(s).
• Écrivez d’abord le commentaire. Décrivez les entrées, les sorties et les cas délicats, comme une entrée vide, des égalités ou des valeurs invalides.
• Gardez les définitions liées dans le même fichier. Copilot n’utilise que le fichier courant, et les longs fichiers sont réduits aux quelques centaines de lignes avant le curseur. GitHub note que coller une déclaration de type dans le fichier sur lequel vous travaillez peut améliorer les suggestions.
• Avancez à petits pas. Demandez une fonction à la fois. L’article sur Codex a constaté que le modèle peine quand une description enchaîne de nombreuses opérations.

Orientez, comparez et gardez les commandes

Copilot ne vous impose rien. Appuyez sur Tab pour accepter une suggestion, continuez à taper pour l’ignorer, ou faites défiler les autres possibilités (sur un Mac, Option-] et Option-[ passent à la suivante et à la précédente). Regarder deux ou trois options est souvent la façon la plus rapide de repérer une suggestion faible, parce que leurs différences montrent où le modèle hésitait.

Si une suggestion est presque bonne, modifiez-la plutôt que de tout recommencer. La page produit indique que Copilot s’adapte aux modifications que vous faites et adopte votre style au fil du travail.

Un exemple concret : commentaire, suggestion, test

Supposons que vous ayez besoin d’une fonction qui convertit une durée comme « 1h30m » en minutes. Commencez par un commentaire et une signature précis :

# Convertit une chaîne de durée comme "1h30m", "45m" ou "2h" en nombre total de minutes.
# Les heures et les minutes sont facultatives, mais au moins l’une des deux doit être présente.
# Lève ValueError pour une entrée vide ou mal formée comme "abc" ou "1x".
def duration_to_minutes(text: str) -> int:

Copilot proposera généralement un corps, peut-être une expression régulière qui capte les heures et les minutes. Avant de l’accepter, lisez-le en gardant trois questions en tête :

1. Gère-t-il chaque cas du commentaire? Vérifiez « 2h » sans minutes et « 45m » sans heures.
2. Que se passe-t-il avec une mauvaise entrée? Bien des solutions rapides retournent 0 pour « abc » au lieu de lever une erreur.
3. Utilise-t-il quelque chose que vous ne reconnaissez pas? Cherchez tout appel de bibliothèque inconnu; GitHub prévient que les suggestions peuvent s’appuyer sur des appels dépassés.

Écrivez ensuite un test. Vous pouvez aussi demander à Copilot d’en ébaucher un, puisque GitHub cite les suggestions de tests parmi ses usages, mais choisissez vous-même les cas :

import pytest

def test_duration_to_minutes():
    assert duration_to_minutes("1h30m") == 90
    assert duration_to_minutes("45m") == 45
    assert duration_to_minutes("2h") == 120
    for bad in ["", "abc", "1x", "h"]:
        with pytest.raises(ValueError):
            duration_to_minutes(bad)

Si le test échoue, vous avez trouvé l’écart entre ce que vous avez demandé et ce que vous avez obtenu. Corrigez le code, ou améliorez le commentaire et redemandez.

Comment vérifier du code que vous n’avez pas écrit?

Lisez-le avant de l’exécuter, et exécutez-le avant de lui faire confiance. Commencez par vous expliquer le code ligne par ligne, ou à voix haute. Toute ligne que vous ne pouvez pas expliquer est une ligne que vous ne comprenez pas encore, et une bonne cachette pour un bogue. Copilot ne teste pas ses suggestions, et GitHub dit clairement qu’elles peuvent ne pas compiler ni fonctionner.

Ensuite, testez le comportement plutôt que l’apparence. Écrivez des cas pour le chemin normal, pour les extrêmes (entrée vide, zéro, très grandes valeurs) et pour les entrées invalides. C’est pour cette raison qu’existe le principal banc d’essai de l’article sur Codex : du code généré qui a l’air correct échoue souvent quand on l’exécute vraiment. Gardez ces tests dans votre projet pour qu’ils protègent le code après vos modifications.

Enfin, vérifiez ce que les tests attrapent rarement. GitHub souligne que le code public contient des pratiques non sécuritaires que Copilot peut répéter; examinez donc de près tout ce qui touche aux entrées des utilisateurs, aux fichiers, aux mots de passe ou aux bases de données, et utilisez les outils de sécurité que vous utiliseriez pour n’importe quel code. Méfiez-vous des adresses courriel ou des clés qui semblent inventées, car le modèle peut en produire à partir de régularités. GitHub estime aussi qu’environ 0,1 % des suggestions contiennent des extraits copiés mot pour mot de son code d’entraînement; si une suggestion ressemble à un bloc de code bien connu, trouvez d’où elle vient avant de la mettre en production. Le code que vous acceptez devient votre code, tout comme la responsabilité qui s’y rattache.