GitHub Enterprise Server 3.22 ouvre Copilot CLI aux réseaux isolés

GitHub Enterprise Server 3.22 est disponible depuis le 8 septembre 2026. Dans son annonce de lancement de GHES 3.22, GitHub confirme l’ouverture de Copilot CLI aux environnements déconnectés ou isolés de GitHub Cloud, tout en maintenant cette capacité en préversion technique.

Le statut doit être lu à deux niveaux : la version 3.22 du serveur est généralement disponible, mais Copilot CLI sur un réseau isolé reste susceptible de changer. En parallèle, Enterprise Teams atteint la disponibilité générale et plusieurs fonctions de règles, de revue de code et de sécurité sont livrées sans cette mention de préversion.

Copilot CLI s’ouvre aux réseaux isolés, en préversion

Un administrateur peut désormais configurer un fournisseur de modèle au niveau de l’instance GHES. Les utilisateurs relient ensuite Copilot CLI au serveur avec leurs identifiants GitHub Enterprise Server, sans que le client ait besoin de se connecter à GitHub Cloud pour suivre ce chemin.

Le mot « isolé » ne garantit cependant pas que toute l’inférence reste dans le réseau interne. Le fournisseur de modèle possède sa propre adresse : s’il se trouve hors du périmètre protégé, les requêtes et le contexte qui lui sont transmis franchissent encore cette limite. Une analyse de la version candidate relevait déjà cette dépendance entre l’isolement réel, l’emplacement du fournisseur et le chemin réseau.

La qualification de préversion technique implique une autre limite : la fonction peut encore évoluer. Pour une équipe d’exploitation, il est donc plus prudent de dissocier le pilote Copilot CLI de la validation du serveur, avec des accès, des journaux et une procédure de désactivation propres au pilote.

Les fonctions administratives au statut stable

Enterprise Teams constitue la principale nouveauté passée explicitement à la disponibilité générale. Les propriétaires d’entreprise peuvent administrer les utilisateurs et leurs accès aux organisations et aux dépôts depuis une structure d’équipe centralisée, au lieu de reproduire les mêmes groupes dans chaque organisation.

Les rulesets gagnent aussi en granularité. Ils peuvent autoriser un utilisateur individuel à contourner une règle, par exemple pour accorder une exception à un compte de service sans créer une équipe ou un rôle dédié. Les propriétaires d’organisation et les administrateurs de dépôt peuvent par ailleurs imposer des équipes de relecture précises, définir un nombre minimal d’approbations par équipe et cibler des branches, fichiers ou dossiers au moyen de motifs.

Cette règle de relecture fonctionne avec CODEOWNERS, qu’elle ne remplace pas. Elle permet d’ajouter l’approbation d’une équipe de sécurité, de qualité ou de conception lorsque les responsables habituels du code ne couvrent pas seuls le contrôle attendu.

Des gains opérationnels plus ciblés

Pour la détection de secrets, les analystes peuvent trier par date, dans les deux sens, les demandes de contournement de la protection au push et les demandes de rejet d’alertes. Le tri est disponible aux niveaux du dépôt, de l’organisation et de l’entreprise ; il facilite la priorisation sans modifier la politique de sécurité appliquée.

Dans les issues, la barre latérale signale maintenant si une pull request associée figure dans la dernière version ou dans une préversion. La liste des pull requests des dépôts publics affiche également le rôle du contributeur, notamment membre, contributeur ou nouvel intervenant.

Ces ajouts sont opérationnels dans la version publiée, mais leur intérêt dépend du profil de l’instance. Les équipes qui centralisent plusieurs organisations, administrent des rulesets complexes ou traitent beaucoup d’exceptions de sécurité en bénéficieront davantage que celles qui exploitent quelques dépôts autonomes.

Une prise en charge annoncée jusqu’en septembre 2027

Le tableau officiel du cycle des versions réunit pour la branche 3.22 la version candidate du 11 août 2026, la sortie générale du 8 septembre 2026 et la fin de prise en charge du 8 septembre 2027, ainsi que CodeQL CLI 2.25.6 comme version recommandée et GitHub Actions Runner 2.334.0 comme version minimale.

Cette fenêtre connue permet de comparer 3.22 à la branche actuellement déployée. Elle ne rend pas la migration urgente dans tous les cas : le bénéfice dépend de la date de fin de support de la version source, des besoins de gouvernance et de la capacité à tester les intégrations avant la fenêtre de maintenance.

La distinction entre support et stabilité fonctionnelle demeure essentielle. GHES 3.22 possède une échéance de prise en charge publiée, tandis qu’aucune date de disponibilité générale n’est actuellement annoncée pour le mode Copilot CLI destiné aux environnements isolés.

Liste de vérification avant la mise à niveau

La préparation doit séparer la compatibilité de la plateforme et le risque propre à la préversion IA. Les contrôles suivants couvrent les changements susceptibles d’influencer directement la décision :

1. valider le chemin de mise à niveau depuis la version installée et inventorier les intégrations, hooks, runners et règles de dépôt concernés ;
2. mettre les runners et les outils CodeQL externes au niveau requis ou recommandé avant la migration lorsqu’ils ne sont pas actualisés automatiquement ;
3. tester la restauration et la durée de l’intervention sur une instance représentative, avec un responsable identifié pour chaque décision de retour arrière ;
4. vérifier Enterprise Teams, les exceptions individuelles aux rulesets et les règles de relecteurs avec plusieurs niveaux de privilèges ;
5. pour Copilot CLI, documenter séparément le fournisseur de modèle, son emplacement, les flux réseau, les certificats, les identifiants et les données envoyées ;
6. définir les critères d’arrêt du pilote IA sans les confondre avec l’acceptation de GHES 3.22 lui-même.

À ce stade, GHES 3.22 est une version généralement disponible et prise en charge, avec plusieurs contrôles administratifs stables. Son ouverture de Copilot CLI aux réseaux isolés est réelle, mais reste une préversion technique dont l’isolement dépend aussi du fournisseur de modèle choisi ; ni son calendrier de stabilisation ni sa future forme définitive ne sont encore précisés.

À lire aussi:

• Twitch ouvre les sponsorings aux Affiliés, sans garantir de campagne
• Salesforce ouvre Headless 360 aux agents, mais le serveur reste bêta
• K2 Horizon ouvre jusqu’aux données d’entraînement, en six tailles