Windows-Copilot-API : transformer l'interface web de Copilot en endpoint OpenAI

Le problème concret : consommer Copilot depuis du code

Copilot, dans sa version grand public, est une interface de chat dans un navigateur. Il n'existe pas de clé d'API associée au compte gratuit, et le README indique que le projet vise précisément ce cas : utiliser son propre compte Microsoft Copilot, sans clé, sans crédits et sans plan payant, en transformant le chat de copilot.microsoft.com en API appelable depuis du code. Le public visé est donc l'utilisateur qui a déjà un compte Copilot fonctionnel, qui écrit du Python, et qui veut brancher un client OpenAI existant sur une source gratuite. Le README mentionne aussi un cas de figure régional : le chemin signé fonctionne là où Copilot anonyme est bloqué, l'Inde étant citée en exemple. Ce n'est pas un outil pour une équipe qui a besoin d'un quota contractuel, d'un engagement de disponibilité ou d'une traçabilité des appels.

Deux modes, un même client

Le dépôt expose deux surfaces distinctes. La première est une bibliothèque Python : `from copilot import CopilotClient`, puis `client.chat("Say hello in one short sentence.")`. La méthode renvoie un objet dont on lit `.text` et `.conversation_id`. Pour poursuivre le même fil, on repasse cet identifiant en second argument : `client.chat("And now in French?", reply.conversation_id)`. Il existe aussi `client.stream(...)`, qui produit la réponse morceau par morceau, l'exemple du README l'utilisant dans une boucle avec `print(chunk, end="", flush=True)`. La seconde surface est un serveur local lancé par `python app.py`, qui écoute sur `http://127.0.0.1:8000` et parle le format OpenAI. On peut alors instancier `OpenAI(base_url="http://localhost:8000/v1", api_key="unused")` et appeler `client.chat.completions.create(model="copilot", messages=[...])`. Le README précise que la clé est exigée par le SDK mais ignorée. Un appel HTTP direct est également documenté avec `curl` sur `/v1/chat/completions`. Le tableau des endpoints ne liste que cette route, avec le support de `"stream": true` ; le reste de la ligne est tronqué dans le matériel fourni, donc je ne peux pas confirmer d'autres routes.

Le mécanisme réel : Playwright, session persistée, clearance Cloudflare

Le point d'architecture qui détermine tout le reste, c'est que le projet ne parle pas à une API. Il pilote un navigateur. L'installation demande `playwright install chromium`, puis `python -m copilot login`, qui ouvre un navigateur visible. Le README décrit la suite : le navigateur se ferme tout seul quand la connexion est détectée, sans appui sur Entrée. Après connexion, le projet envoie un court message d'échauffement qui, selon le README, fabrique le jeton de chat et franchit dans le même mouvement la vérification Cloudflare « verify you're human », avec une brève mention « finishing setup… » et un message jetable qui apparaît dans l'historique. Si une case à cocher s'affiche, il faut la cliquer dans cette fenêtre. La session est ensuite stockée sous `session/`, dossier ignoré par git selon le README, et réutilisée à chaque exécution. Les journaux de cette étape vont dans `session/login.log`. C'est cette dépendance à une session navigateur, et non à un secret d'API, qui explique la plupart des contraintes décrites plus loin.

Docker : ce que le conteneur ne peut pas faire

Le mode conteneur est documenté, mais avec une réserve explicite qui mérite d'être lue avant de s'engager. Le README indique que la connexion doit être faite sur l'hôte, parce que l'étape de login ouvre un navigateur visible qui ne peut pas tourner dans un conteneur headless. La commande est donc `python -m copilot login` sur la machine hôte, pour peupler `session/`, que le conteneur monte ensuite. Le conteneur rafraîchit le jeton de chat sans interface graphique, mais ne peut pas obtenir une clearance neuve sans navigateur visible. Conséquence chiffrée dans le README : quand la clearance expire, au bout d'environ 30 minutes, le serveur renvoie un `503`, et il faut relancer la connexion sur l'hôte pour rafraîchir `session/`. Le fichier `docker-compose.yml` mappe le port `8000`, monte `session/` et expose les clés `RATE_LIMIT_RPM` et `RATE_LIMIT_BURST` comme réglages. Une exécution sans Compose est aussi donnée, avec `docker build -t windows-copilot-api .` puis `docker run --rm -p 8000:8000 -v "$(pwd)/session:/app/session" windows-copilot-api`. Ce n'est donc pas un service qu'on laisse tourner des semaines sans intervention.

Limites assumées et cas où l'outil ne convient pas

La limitation la plus structurante est temporelle : la clearance Cloudflare expire, et le README donne environ 30 minutes en contexte Docker. En dehors de Docker, le mécanisme de rafraîchissement n'est pas détaillé dans le matériel fourni, et je ne peux pas affirmer combien de temps une session hôte reste valide. Deuxième limite : le contrôle des paramètres de génération. Le README ne mentionne ni `temperature`, ni `max_tokens`, ni les sorties structurées, ni le choix effectif de modèle. Le nom de modèle utilisé dans les exemples est `copilot`, une étiquette unique, alors que la description du dépôt évoque l'accès à des modèles GPT-4 et GPT-5 ; le README, lui, ne documente pas de sélection par identifiant. Troisième point : le projet automatise l'expérience web grand public de Copilot, ce que le README présente lui-même comme non officiel, non affilié à Microsoft, et à utiliser dans le respect des conditions du service. Cela exclut de fait les usages où l'on doit pouvoir justifier la provenance d'un appel auprès d'un tiers, ou tenir une charge soutenue avec plusieurs utilisateurs simultanés. Un test de charge est mentionné dans la table des matières, mais son contenu n'est pas fourni ici.

Face à une clé d'API classique : la différence de nature

L'alternative évidente est une API hébergée avec clé et facturation à l'usage, du type de celles que le SDK `openai` cible par défaut. La différence n'est pas une question de qualité de réponse, mais de contrat. Avec une clé, l'authentification est un secret stable que l'on peut ranger dans un gestionnaire de secrets, tourner, révoquer, et partager entre plusieurs machines sans navigateur. Ici, l'authentification est un profil de navigateur et un cookie de clearance, avec une durée de vie courte et une étape interactive obligatoire à intervalles réguliers. Une clé se prête à un déploiement headless, à de l'intégration continue et à plusieurs instances en parallèle ; une session Playwright, non, du moins pas sans la relancer. En contrepartie, la clé coûte de l'argent et exige un compte fournisseur, ce que ce projet évite. Le choix se joue donc entre un coût monétaire et un coût opérationnel : la session à rafraîchir, le `503` à surveiller, l'étape manuelle à prévoir dans un runbook. Pour un script personnel lancé à la demande, l'arbitrage penche clairement du côté de ce projet. Pour un service, il ne tient pas.

Maintenance, licence et ce qu'il faut vérifier avant d'adopter

Le dépôt est sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un contexte commercial, sous réserve de conserver la mention de licence. Le README rappelle par ailleurs que le projet est non officiel et non approuvé par Microsoft : la licence MIT couvre le code du dépôt, pas l'accès au service Copilot, dont les conditions d'utilisation restent celles de Microsoft et s'appliquent indépendamment. Ce point mérite une lecture attentive si l'usage envisagé est professionnel. Côté maintenance, le coût est concentré sur une seule chose : le maintien en état de la chaîne Playwright et de la détection de connexion. Toute évolution de la page de connexion, de la vérification Cloudflare ou du flux de jeton peut casser `python -m copilot login` sans prévenir, et le diagnostic fourni avec le projet est présenté comme capable de corriger les problèmes courants de captcha et de clearance tout en produisant un rapport partageable. La version de Python requise est 3.9 ou plus, et le projet fonctionne sur Windows, macOS et Linux selon le README. Aucune release n'a été récupérée dans les métadonnées fournies, donc je ne peux pas commenter le rythme de publication. Le dernier push observé date du 27 juin 2026.

Conclusion éditoriale

À adopter pour un usage personnel ou un prototype Python sur une machine où l'on peut ouvrir un navigateur visible une fois, et où l'on accepte de relancer `python -m copilot login` quand la clearance expire. À éviter en production multi-utilisateurs, en CI headless, ou si l'on a besoin des paramètres `temperature`, `max_tokens` et du format de réponse structuré : le README ne les mentionne pas. Avant tout déploiement, vérifier la durée de vie réelle de la session dans `session/` et le comportement du serveur au-delà de la limite `RATE_LIMIT_RPM`.

Sources officielles

1. Issues
2. License: MIT
3. README
4. sums001/Windows-Copilot-API on GitHub