Valider une réponse : accepter, modifier ou refuser

1.7 Validation humaine : comment vérifier une réponse Copilot ?

Checklist de validation

Quand Copilot génère une réponse, vérifie :

• Est-ce que le code compile ?
• Est-ce que les tests passent ?
• Est-ce que le code est sécurisé ?
• Est-ce que les inputs sont validés ?
• Est-ce que les erreurs sont gérées ?
• Est-ce que les dépendances sont maintenues ?
• Est-ce que le code respecte les standards de l’équipe ?
• Est-ce que le code est lisible ?
• Est-ce que la solution est adaptée au contexte ?
• Est-ce qu’il y a un risque de fuite de données ?
• Est-ce que le code respecte les règles de l’entreprise ?

Exemple de prompt de validation

Après une suggestion Copilot, tu peux demander :

Review this code for security issues, edge cases, and maintainability problems.

Ou plus précis :

Analyze this Node.js Express route for injection risks, authentication issues, authorization flaws, and error handling problems.

Encore mieux :

Suggest unit tests and edge cases for this function. Focus on invalid inputs, boundary values, and security-sensitive cases.

1.8 Accepter, modifier ou refuser une suggestion Copilot

Cas 1 : Accepter directement

Tu peux accepter une suggestion simple si elle est peu risquée.

Exemple :

def format_username(first_name: str, last_name: str) -> str:
    return f"{first_name.strip().title()} {last_name.strip().title()}"

Même ici, il faut comprendre ce que ça fait, mais le risque est faible.

Cas 2 : Modifier avant d’accepter

Copilot propose :

def divide(a, b):
    return a / b

Tu modifies :

def divide(a: float, b: float) -> float:
    if b == 0:
        raise ValueError("Division by zero is not allowed")
    return a / b

Pourquoi ? Parce que tu ajoutes :

• typage ;
• gestion d’erreur ;
• comportement explicite.

Cas 3 : Refuser la suggestion

Copilot propose :

def verify_password(input_password, stored_password):
    return input_password == stored_password

Problèmes :

• comparaison directe ;
• pas de hash ;
• pas de protection timing attack ;
• mauvaise pratique sécurité.

Tu refuses et tu demandes une approche plus sûre.

Prompt amélioré :

Rewrite this password verification function using a secure password hashing library and constant-time comparison where appropriate.

1.12 Comment reconnaître une mauvaise réponse Copilot ?

Signaux d’alerte

Attention si la réponse :

• utilise une librairie inconnue ;
• utilise une API que tu ne reconnais pas ;
• ne gère pas les erreurs ;
• ignore la sécurité ;
• hardcode des secrets ;
• utilise des permissions trop larges ;
• fait des hypothèses non dites ;
• modifie trop de choses à la fois ;
• ne respecte pas ton architecture ;
• donne une explication trop confiante mais vague ;
• propose une commande destructive ;
• utilise des fonctions dépréciées.

Exemple de commande dangereuse

Copilot peut proposer :

rm -rf /tmp/*

Ce n’est pas forcément dramatique.

Mais s’il propose :

rm -rf /*

Là, c’est catastrophique.

Avec le CLI et les commandes shell, il faut toujours vérifier :

• le chemin ;
• les options ;
• les permissions ;
• l’impact ;
• les fichiers supprimés ou modifiés ;
• les commandes réseau ;
• les commandes d’installation ;
• les commandes avec sudo.

1.15 Checklist Responsible AI avant d’accepter une suggestion ✅

Avant d’accepter une suggestion Copilot, demande-toi :

• Est-ce que je comprends le code ?
• Est-ce que le code répond vraiment au besoin ?
• Est-ce que les inputs sont validés ?
• Est-ce que les erreurs sont gérées ?
• Est-ce que le code expose des secrets ?
• Est-ce que les permissions sont minimales ?
• Est-ce que le code utilise des dépendances maintenues ?
• Est-ce que le code est testé ?
• Est-ce que le code respecte les standards de l’équipe ?
• Est-ce que le code doit être revu par un humain ?
• Est-ce que le domaine est sensible ?
• Est-ce que je dois vérifier la documentation officielle ?

Si plusieurs réponses sont négatives, ne l’accepte pas directement.