Proxy, post-processing et cycle de vie

7.6 Proxy filtering 🛂

Définition

Le proxy filtering est une étape de filtrage entre l’environnement utilisateur et les services Copilot.

Dans le contexte GH-300, il faut comprendre que GitHub Copilot ne se résume pas à :

IDE → modèle → réponse

Il y a des services intermédiaires qui peuvent appliquer des règles, filtrer, préparer ou contrôler certaines données avant ou après l’appel au modèle.

Le guide officiel GH-300 cite explicitement le proxy filtering dans le bloc Data handling and architecture. (learn.microsoft.com)

Précision de vocabulaire : « proxy filtering » est le terme du guide d’examen. GitHub ne détaille pas publiquement les étapes internes de cette partie du flux. Le chapitre l’enseigne donc comme un modèle conceptuel : retiens son rôle (un contrôle entre l’environnement utilisateur et le modèle), pas une implémentation.

Définition accessible

Tu peux voir le proxy filtering comme un point de contrôle.

Conceptuellement :

Ce que GitHub documente

GitHub décrit un système de filtrage de contenu (content filtering) qui analyse les prompts et les réponses pour détecter et bloquer des contenus nuisibles, offensants ou non sûrs avant qu’ils soient affichés. Selon la surface, ce filtrage peut être actif ou non : la documentation de Copilot Chat parle de filtrage « lorsqu’il est activé ». Le filtrage s’applique donc aux deux sens : ce qui entre (le prompt) et ce qui sort (la réponse). Microsoft Learn emploie aussi le terme « toxicity filtering » pour cette étape.

À quoi peut servir ce type d’étape ?

Dans le modèle conceptuel du cours, une étape de ce type peut :

• router la requête ;
• appliquer des règles ;
• limiter certains contenus ;
• préparer le prompt.

Attention à ne pas confondre

Il y a deux notions différentes :

1. Proxy filtering dans l’architecture Copilot

C’est une logique interne de traitement/filtrage des requêtes et réponses Copilot.

2. Proxy réseau d’entreprise

C’est le proxy/firewall de ton entreprise.

GitHub documente aussi les paramètres réseau Copilot pour permettre la connexion via proxy HTTP ou certificats personnalisés en environnement corporate. (docs.github.com)

Exemple entreprise

Une entreprise a un proxy réseau strict.

Elle doit autoriser certaines connexions pour que Copilot fonctionne.

GitHub fournit une allowlist de domaines nécessaires pour Copilot. (docs.github.com)

Mais cela ne veut pas dire que ce proxy réseau fait tout le traitement logique de Copilot.

Proxy filtering = étape de contrôle/filtrage dans le flux Copilot.
Proxy réseau = configuration d’entreprise pour permettre la connexion.

7.7 Post-processing 🧽

Définition

Le post-processing est le traitement effectué après la génération d’une réponse par le modèle, avant que la réponse finale ne soit affichée à l’utilisateur.

Le guide officiel GH-300 mentionne explicitement le post-processing dans le data flow Copilot. (learn.microsoft.com)

Ce que GitHub documente

GitHub décrit le traitement d’une demande dans Copilot Chat en quatre temps : le traitement de l’entrée (le prompt est pré-traité et combiné au contexte), l’analyse par le modèle, la génération de la réponse, puis la mise en forme de la sortie (coloration syntaxique, indentation, liens vers le contexte utilisé). Pour les suggestions inline, les suggestions générées sont passées dans des filtres de contenu avant d’être affichées. Le post-processing du guide d’examen désigne cette partie : ce qui se passe après que le modèle a répondu et avant que tu voies le résultat.

À quoi ça sert ?

Le post-processing peut servir à :

• filtrer certaines réponses ;
• vérifier des correspondances avec du code public ;
• ajuster le format et l’affichage ;
• masquer ou bloquer certaines suggestions ;
• fournir des références de code public quand applicable.

Trois contrôles à distinguer

• Content filtering : atténuer ou bloquer des contenus nuisibles, offensants ou non sûrs dans le flux concerné.
• Suggestions matching public code : détecter une correspondance entre une suggestion produite et du code public, puis bloquer ou fournir des références selon le réglage.
• Content exclusions : empêcher, lorsque la surface le prend en charge, certains contenus du dépôt d’être utilisés comme contexte.

Ces contrôles n’ont ni le même objet ni le même moment dans le flux. Le chapitre 11 porte la configuration des deux derniers ; ici, le filtrage de contenu est le concept canonique d’architecture.

Exemple : suggestions correspondant à du code public

GitHub indique qu’un utilisateur peut choisir de bloquer les suggestions qui correspondent à du code public. Dans la plupart des produits Copilot, GitHub compare alors la suggestion et environ 150 caractères de contexte avec du code public sur GitHub ; en cas de correspondance ou quasi-correspondance, la suggestion n’est pas affichée. (docs.github.com)

Ce mécanisme illustre bien l’idée de post-processing :

Le modèle génère une suggestion.
Copilot vérifie certains critères.
La suggestion peut être affichée ou bloquée.

Exemple visuel

Exemple concret

Copilot génère une suggestion qui ressemble fortement à du code public connu.

Si la policy de blocage est activée :

Suggestion bloquée ou non affichée.

Si la fonctionnalité de référence est disponible :

Copilot peut fournir des références vers du code public correspondant.

GitHub documente aussi la possibilité de trouver du code public correspondant aux suggestions Copilot via les code references. (docs.github.com)

7.8 Cycle de vie d’une suggestion de code 🔁

Vue d’ensemble

Le cycle de vie d’une suggestion Copilot peut être résumé comme ceci :

1. Le développeur écrit ou demande quelque chose
2. Copilot collecte le contexte pertinent
3. Copilot construit le prompt
4. Le prompt passe par des services/filtrages
5. Le modèle génère une réponse
6. Copilot applique du post-processing
7. La suggestion est affichée
8. Le développeur accepte, modifie ou refuse
9. Le code est testé, revu et validé

Le guide GH-300 demande explicitement de savoir visualiser le code suggestion lifecycle. (learn.microsoft.com)

Ces neuf moments sont un résumé pédagogique. GitHub documente le cœur de la chaîne en quatre temps (traitement de l’entrée, analyse par le modèle, génération, mise en forme de la sortie) : ici, ils correspondent aux moments 2 à 7, et les moments 1, 8 et 9 sont ceux du développeur.

Exemple complet

Tu écris :

def slugify(title: str) -> str:

Étape 1 : Input utilisateur

Tu commences une fonction.

Étape 2 : Contexte

Copilot voit potentiellement :

• fichier courant
• imports
• nom de fonction
• type hints
• commentaires
• style du code

Étape 3 : Prompt building

Copilot construit une requête du genre :

Generate Python implementation for slugify(title: str) -> str
following current file style.

Étape 4 : Services et filtrages

La demande passe par les services Copilot, où des contrôles peuvent s’appliquer. Tu ne vois pas cette étape.

Étape 5 : Modèle

Le modèle génère :

import re

def slugify(title: str) -> str:
    slug = title.lower().strip()
    slug = re.sub(r"[^a-z0-9]+", "-", slug)
    return slug.strip("-")

Étape 6 : Post-processing

Copilot peut appliquer des contrôles avant affichage.

Étape 7 : Affichage

Tu vois la suggestion dans ton IDE.

Étape 8 : Accepter, modifier ou refuser

Tu dois te demander :

• Que se passe-t-il avec les accents ?
• Que se passe-t-il avec None ?
• Faut-il supporter Unicode ?
• Faut-il ajouter des tests ?

Étape 9 : Tests et review

Tu ajoutes :

def test_slugify_basic():
    assert slugify("Hello World!") == "hello-world"

def test_slugify_strips_extra_spaces():
    assert slugify("  Hello   World  ") == "hello-world"

Puis tu complètes peut-être pour Unicode selon besoin.

Pourquoi cet ordre ?

Chaque moment dépend de ce que produit le précédent :

• le contexte doit être collecté avant de construire le prompt, qui n’existe pas sans lui ;
• le prompt doit exister avant que le modèle puisse répondre ;
• la réponse doit exister avant d’être filtrée ou mise en forme : on ne filtre pas ce qui n’est pas encore généré ;
• rien n’est affiché avant la fin du traitement de la réponse ;
• le développeur ne peut accepter, tester ou relire qu’une suggestion qu’il voit.

Conséquence pratique : ce que tu fournis comme contexte et comme instructions agit avant le modèle ; les filtres et la mise en forme agissent après lui ; ta validation vient en dernier.

Point important

Le cycle ne s’arrête pas quand Copilot affiche une suggestion.

Il s’arrête quand :

le développeur a relu, testé, validé et intégré le code.