Résumé

  • GitHub a ouvert l’incident 7s119p1yxttr le 3 août à 09 h 53 min 27,172 s UTC et l’a résolu à 11 h 25 min 12,371 s, soit 1 heure, 31 minutes et 45,199 secondes.
  • L’entreprise a signalé une disponibilité dégradée des modèles de conversation et d’agent de Copilot, plusieurs modèles étant concernés et certaines requêtes pouvant échouer.
  • Des erreurs intermittentes persistaient à 10 h 35 min 19,914 s; la correction a été annoncée à 11 h 19 min 04,001 s, puis surveillée pendant 6 minutes et 8,370 secondes.
  • L’incident est classé « minor », sans volume de requêtes, taux d’échec, nombre d’utilisateurs ou d’organisations, répartition géographique, liste de modèles ni durée par client.
  • GitHub a promis une analyse détaillée; à l’heure de clôture de cette édition, la cause, la méthode de correction, les règles de nouvelle tentative et le sort des tâches d’agent en file restaient inconnus.

Un seul composant public, plusieurs chemins d’exécution

La page d’état ne nomme qu’un composant: Copilot. La mise à jour de 09 h 54 min 22,985 s précise pourtant une surface plus complexe. GitHub y indique que la disponibilité des modèles de conversation et d’agent est dégradée, que plusieurs modèles sont touchés et que des requêtes peuvent échouer.

Cette formulation ne permet pas de parler d’un arrêt total. Certaines demandes ont pu aboutir pendant toute la période; GitHub ne fournit pas la proportion. Elle empêche aussi de réduire l’événement à un modèle isolé. Comme la liste n’est pas donnée, choisir un autre modèle n’aurait pas constitué un contournement vérifié par la communication publique.

La distinction entre conversation et agent change la portée opérationnelle. Une réponse de chat absente est immédiatement visible. Une tâche d’agent peut avoir consulté un dépôt, appelé un outil, préparé une modification ou lancé un test avant l’échec. Le dossier ne dit pas qu’une opération précise a été perdue ou dupliquée. Il montre en revanche pourquoi l’état d’une demande longue ne se résume pas à « reçu » ou « erreur ».

L’intermittence crée un travail de rapprochement

À 10 h 35 min 19,914 s, plus de quarante et une minutes après l’ouverture, GitHub observait encore des erreurs intermittentes et examinait des mesures correctives. Dans une telle période, une requête réussie ne prouve pas que les précédentes ont abouti; un message d’erreur ne signifie pas non plus que tout le trafic a échoué.

Pour les agents, le point décisif est l’accusé de prise en charge. La tâche a-t-elle été acceptée ? Est-elle restée active ? L’échec a-t-il précédé l’exécution ou interrompu une séquence déjà engagée ? Une nouvelle tentative crée-t-elle une deuxième opération ? La page d’état ne décrit pas les files ni l’idempotence de Copilot, de sorte qu’aucune réponse ne peut être attribuée à cet incident.

Une entreprise peut toutefois réduire l’incertitude en conservant identifiants et heures de requête lorsqu’ils sont disponibles, en vérifiant l’état réel du dépôt ou du ticket avant toute relance, et en séparant panne de transport, échec d’exécution et validation du résultat. Il s’agit d’une discipline de continuité, pas d’une affirmation selon laquelle Copilot aurait altéré du code le 3 août.

La correction et la clôture ont deux horaires

À 11 h 19 min 04,001 s, GitHub a déclaré la dégradation corrigée et est passé en surveillance. Le composant Copilot est alors revenu de « degraded performance » à « operational ». La résolution administrative a suivi à 11 h 25 min 12,371 s, après 6 minutes et 8,370 secondes d’observation.

Cet intervalle montre une phase de vérification, sans révéler la technique employée. Aucun basculement de trafic, ajout de capacité, retour de version, isolement de dépendance ou changement de politique n’est décrit. Présenter l’un de ces mécanismes comme la cause de la reprise serait inventer un fait.

La durée publique complète atteint 1 h 31 min 45,199 s. C’est l’horloge du dossier fournisseur, pas celle de chaque client. L’exposition individuelle a pu être plus brève, discontinue ou inexistante. À l’inverse, une tâche acceptée avant le retour à l’état opérationnel peut exiger un contrôle ultérieur. La reprise du composant ne certifie pas l’achèvement de tous les travaux antérieurs.

« Minor » ne remplace pas un dénominateur

Le niveau « minor » sert à classer l’événement dans le système d’état de GitHub. Il ne donne ni pourcentage ni seuil contractuel. Il manque le nombre total de requêtes Copilot, le volume d’échecs, la distribution de latence, les utilisateurs et organisations touchés, les régions concernées et l’exposition par modèle.

Sans ces données, une même étiquette recouvre des expériences opposées. Une équipe sans agent actif peut n’avoir rien remarqué; une autre, dépendante d’une demande échouée dans un processus de revue ou d’assistance, peut avoir subi une interruption substantielle. Le dossier public ne permet pas d’en estimer la fréquence respective.

Il ne permet pas davantage de relier cette panne aux incidents précédents de modèles chez GitHub. Cette fois, aucun fournisseur amont n’est cité et aucune cause commune n’est avancée. La proximité temporelle et le même nom de produit ne constituent pas une preuve causale.

Aucun itinéraire de secours n’a été validé

Les mises à jour publiques ne recommandent ni de changer de modèle, ni de choisir Auto, ni de suspendre les agents, ni de réessayer après un délai donné. Cette absence est importante lorsque plusieurs modèles non nommés sont concernés: un simple changement de sélection ne garantit pas la sortie de la zone dégradée.

Cela ne prouve pas qu’aucune route alternative n’existait. Cela signifie seulement que GitHub n’en a validé aucune dans la communication de l’incident. Les clients doivent donc décider à l’avance quelles tâches peuvent être rejouées automatiquement, lesquelles exigent un accord humain si le modèle change, et quelles écritures nécessitent d’abord une vérification externe.

La continuité d’un outil d’IA ne consiste plus uniquement à obtenir une autre réponse. Dès que l’agent agit sur un système, elle consiste à savoir ce qui a été accepté, exécuté et confirmé avant de recommencer.

La disponibilité est revenue avant l’explication

Lors de la clôture, GitHub a annoncé qu’une analyse détaillée de la cause serait publiée. À la date fixe de cette édition, les sources de première main ne contenaient ni cause ni description de la correction. Elles ne mesuraient pas non plus le délai de détection, la part des demandes échouées ou retardées, le succès des relances, le sort des files ni la différence entre chat et agent.

Une analyse utile devrait cartographier la frontière commune aux modèles touchés, expliquer l’intermittence, décrire la détection et la correction, puis dire si les tâches d’agent déjà acceptées ont dû être rejouées ou rapprochées. Un volume total rendrait aussi le niveau « minor » interprétable.

La conclusion reste donc bornée: Copilot a été rétabli après un incident public de 92 minutes environ, marqué par des échecs intermittents sur plusieurs chemins de conversation et d’agent. Le mécanisme et l’exposition mesurée des clients ne sont pas encore publics.

Sources