Le jour où GitHub Copilot te coupe l’accès « pour comportement suspect », tu comprends deux choses très vite. Un, ce n’est pas une panne. Deux, ton usage ressemble suffisamment à de l’automatisation agressive pour déclencher une détection d’abus. Et oui, ça peut arriver alors que tu n’as rien “piraté” et que tu bosses juste… trop vite, trop en boucle, trop comme un script.
L’objectif ici n’est pas de jouer au juriste ni de commenter les CGU. Je veux te donner un cadre pratico-pratique : quels patterns font “bot” (surtout avec des agents/CLI), comment les casser sans perdre tout le bénéfice, et comment te débrouiller si ça tombe au pire moment, typiquement en deadline ou en incident.
Le mail « comportement suspect » : ce que ça vise réellement
Quand une plateforme parle de « comportement suspect », ça vise rarement ton intention. Ça vise des signaux. Une fréquence de requêtes anormale, des patterns répétitifs, des bursts impossibles à produire à la main, des sessions qui sautent d’un environnement à l’autre, ou un usage qui ressemble à de la ré-exécution automatique sans contrôle humain.
Le malaise avec Copilot, c’est que les nouveaux usages (Copilot en CLI, modes agents, itérations rapides) miment exactement ce que les systèmes anti-abus essaient de stopper depuis dix ans : du trafic “scripted”. Tu peux être un développeur parfaitement légitime… et quand même cocher des cases du mauvais côté.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Pourquoi les agents et la CLI font vite “bot”, même quand tu es devant l’écran
Un IDE, historiquement, a un rythme humain. Tu tapes, tu réfléchis, tu lances un test, tu lis un diff. Même si Copilot suggère beaucoup, il y a de l’inertie. Avec une CLI ou un agent qui enchaîne des actions, tu supprimes cette inertie. Tu peux envoyer des prompts à la chaîne, relancer 20 fois une commande, itérer sans pause sur une erreur, et multiplier les appels sans t’en rendre compte.
Ajoute à ça les workflows “modernes” qu’on voit partout : plusieurs terminaux, plusieurs dossiers, parfois un second poste ou une VM, et des outils qui relancent automatiquement quand ça échoue. Vu de l’extérieur, ça ressemble à une boucle. Vu de toi, c’est juste « je débloque un problème ».
Les signaux qui ressemblent à de l’abus dans un workflow dev
Le premier signal, c’est le volume concentré. Typiquement, un enchaînement de requêtes très rapprochées sur une courte période. Ça arrive quand tu joues avec un agent, que tu testes des variantes de prompt, ou que tu fais du “retry” frénétique parce que la réponse ne te convient pas. C’est humain dans la tête, c’est mécanique dans les logs.
Le deuxième signal, c’est la répétition quasi-identique. Même commande, même prompt, mêmes paramètres, même repo, encore et encore. Un humain varie un peu sans le vouloir. Un script, non. Et les agents, eux, sont capables de répéter très proprement une séquence jusqu’à obtenir un résultat acceptable.
Le troisième signal, c’est l’automatisation qui te dépasse. Le piège classique est de laisser un outil auto-exécuter une série d’actions “pour t’aider”, puis de le laisser tourner pendant que tu fais autre chose. Tu restes responsable, mais tu n’es plus dans la boucle. Dans beaucoup de systèmes anti-abus, “pas de friction” = “suspect”.
Le quatrième signal, plus subtil, c’est l’environnement. Une session qui semble sauter entre plusieurs machines, plusieurs adresses IP, ou plusieurs contextes à un rythme bizarre. Par exemple : tu bosses en coworking, puis en partage de connexion, puis via une VM, puis via un VPN. Je ne dis pas que c’est interdit. Je dis que ça ressemble vite à une compromission de compte… et les systèmes préfèrent bloquer que réfléchir.
Hygiène de workflow : garder Copilot utile sans déclencher l’alarme
Le geste le plus rentable, c’est de remettre de la friction volontaire. Pas “travailler plus lentement”, mais casser les rafales et les boucles. Quand tu sens que tu pars en mode machine à sous (« encore une suggestion », « encore un run », « encore un prompt »), impose-toi des micro-pauses. Dix secondes peuvent suffire à faire retomber un burst dans des métriques “humaines”.
Ensuite, évite l’auto-exécution aveugle. Les modes agents donnent envie de déléguer, et c’est normal. Mais si l’outil peut enchaîner des commandes, limite-le. Mets-le dans un bac à sable. Fais-le bosser sur une branche dédiée. Et surtout, garde un point de validation où tu relis avant que ça touche ton repo, tes secrets, ou tes environnements. C’est bon pour la sécurité, et c’est aussi un signal : il y a bien un humain qui pilote.
Troisième point : arrête de “retry” comme un script. Si tu dois relancer parce que ça rate, fais-le proprement, avec backoff et un peu d’aléatoire. C’est bête, mais c’est exactement ce qu’on met en place côté API quand on ne veut pas se faire classer en abuse.
#!/usr/bin/env bash
# Exemple simple : retries avec backoff + jitter, pour éviter les boucles trop “scriptées”.
# Adapte la commande à ton usage Copilot CLI / agent.
set -euo pipefail
max=6
base=1
for i in $(seq 1 $max); do
if copilot some-command "ton prompt"; then
exit 0
fi
# backoff exponentiel + jitter
sleep_time=$(( base * (2 ** (i-1)) + (RANDOM % 3) ))
echo "Retry $i/$max, pause ${sleep_time}s" >&2
sleep "$sleep_time"
done
echo "Abandon après $max tentatives" >&2
exit 1
Quatrième point : logge ton usage. Pas pour faire plaisir à qui que ce soit, mais pour toi. Si tu te fais suspendre, tu veux savoir ce qui s’est passé dans l’heure précédente : combien d’appels, combien de retries, quelle commande, quel contexte. Et si tu ouvres un ticket, avoir une chronologie claire, c’est souvent la différence entre « réponse générique » et « investigation sérieuse ».
Enfin, évite les setups “partagés” qui crient abuse. Un compte utilisé par deux personnes. Un poste et une CI qui déclenchent en parallèle. Un agent qui tourne sur une VM pendant que tu utilises l’IDE. Même si tu ne fais rien de mal, tu fabriques un pattern difficile à défendre. Copilot, ce n’est pas un worker pool.
Quand tu es suspendu : plan de sortie en 30 minutes (sans t’éparpiller)
Quand ça tombe, la première erreur est de paniquer et d’essayer quinze trucs en même temps. Commence par stopper ce qui peut continuer à générer du trafic : agents en arrière-plan, shells ouverts, tâches planifiées, extensions qui spamment des suggestions. Tant que ça tourne, tu risques juste d’empirer le signal.
Ensuite, capture le contexte. Le mail ou la notification, l’heure, ce que tu faisais, les commandes lancées, ton environnement réseau (VPN oui/non, changement de connexion), et les éventuels logs que tu as. Tu n’as pas besoin d’écrire un roman, mais tu veux quelque chose de factuel et vérifiable.
Puis seulement tu contactes le support officiel via GitHub. L’idée n’est pas d’argumenter sur le fond (« je suis gentil »), mais d’expliquer ton workflow. « J’utilisais Copilot via la CLI / un mode agent pour itérer, j’ai eu des retries, voilà la fenêtre horaire, voilà ce que j’ai stoppé pour éviter toute boucle. » Ça ressemble à une procédure d’incident, et c’est exactement ce que c’est.
Dernier point, très terrain : préviens ton équipe ou ton client si Copilot était une dépendance implicite de ta vélocité. Pas pour te justifier, juste pour ajuster la réalité. Si ton plan de prod reposait sur « je vais itérer avec Copilot toute la nuit », tu viens de perdre un outil. Autant le dire tôt et reprendre le contrôle.
Plan B : continuer à livrer sans Copilot (parce que ça arrivera encore)
Le vrai bug, ce n’est pas la suspension. C’est d’avoir un workflow où tu ne sais plus bosser sans. Donc tu veux une continuité minimale. Concrètement : un IDE prêt à tourner sans Copilot, tes raccourcis, tes templates, une doc locale de ton projet, et une façon propre de faire du scaffolding sans IA. Ça peut être des snippets, des générateurs internes, ou juste des commandes que tu maîtrises.
Si tu utilises des agents pour explorer rapidement, garde une alternative hors-ligne ou au moins “d’un autre fournisseur”, mais surtout garde la séparation. Ne remplace pas « dépendance Copilot » par « dépendance à un autre SaaS » sans changer tes habitudes. Le sujet n’est pas le fournisseur. Le sujet, c’est l’absence de garde-fous quand tu automatises.
Et si tu es freelance, petit conseil pas glamour : sécurise ta facturation et tes délais avec une marge. Les outils IA peuvent te faire gagner du temps. Ils peuvent aussi te le reprendre d’un coup, sans discussion, le jour où ton workflow ressemble trop à un bot. C’est un risque opérationnel, pas une “feature”.
Mon avis : l’IA en dev, ça marche mieux quand tu la rends ennuyeuse
Les usages les plus stables que j’ai vus, ce ne sont pas les setups impressionnants où un agent fait tout. C’est l’IA qui reste dans son couloir : aider à écrire, aider à refactor, aider à comprendre une base de code, proposer des tests, accélérer un diff. Dès que tu la mets en boucle et que tu la laisses “piloter” trop longtemps, tu gagnes peut-être dix minutes… et tu t’exposes à une coupure au pire moment.
Rends ton usage plus ennuyeux : des pauses, des validations humaines, des retries propres, un peu d’observabilité. Tu perds un peu de dopamine. Tu gagnes en fiabilité. Et paradoxalement, c’est comme ça que l’IA devient un vrai outil de production, pas un gadget qui t’abandonne en sprint final.
