GitHub Actions : tes runs et logs s’effacent plus vite depuis le 1er octobre

Depuis le 1er octobre 2026, tes checks, exécutions de workflow et statuts GitHub Actions ne vivent plus indéfiniment : ils suivent désormais la même politique de rétention que les artefacts et les logs. Si tu n’as jamais touché à ce réglage, la limite par défaut tombe à 90 jours — et pour les dépôts publics, c’est un plafond dur qu’aucune configuration ne permet de dépasser.

Ce qui a changé le 1er octobre

Avant ce changement, les checks, les runs de workflow et les statuts créés par Actions (et par des applications tierces) pouvaient rester visibles plus de 400 jours, indépendamment du réglage de rétention des artefacts et des logs. GitHub a annoncé l’alignement de ces trois types de données sur cette même politique le 27 août 2026, avec une bascule confirmée effective le 1er octobre. Le paramètre dans les réglages du dépôt a d’ailleurs été renommé pour refléter ce périmètre élargi : il s’appelle désormais « Check, workflow run, status, artifact and log retention » plutôt que de ne mentionner qu’artefacts et logs.

La raison donnée par GitHub est double : simplifier l’administration (un seul réglage à surveiller au lieu de plusieurs politiques implicites) et réduire la facture de stockage pour les dépôts qui, sans le savoir, conservaient des données bien au-delà de ce qu’ils avaient configuré pour les artefacts.

Les chiffres à retenir

La rétention se configure à trois niveaux — dépôt, organisation, entreprise — chacun pouvant resserrer mais jamais dépasser le plafond fixé au niveau supérieur. Deux chiffres à garder en tête : 90 jours par défaut, et 90 jours de plafond absolu pour les dépôts publics, quel que soit le réglage souhaité au niveau dépôt. Un dépôt privé peut viser plus large si son organisation l’autorise, un dépôt public open source non.

L’impact concret pour toi

Deux conséquences directes. D’abord, côté conformité et audit : si tu t’appuies sur l’historique des checks ou des statuts de commit comme preuve qu’une PR a bien passé tes contrôles qualité à une date donnée, cette preuve disparaît désormais au bout de 90 jours sauf configuration explicite plus large. Ensuite, côté facturation : artefacts et logs comptent dans le stockage Actions facturable, donc un repository qui conservait ses données plus longtemps que prévu par erreur devrait voir sa facture de stockage baisser mécaniquement.

Ce qui est supprimé ne revient pas. GitHub est explicite là-dessus : les enregistrements qui dépassaient déjà la période configurée au moment de la bascule ont été nettoyés automatiquement, sans fenêtre de rattrapage.

Comment vérifier et ajuster ta configuration

Le réglage se trouve dans Settings > Actions > General de chaque dépôt (ou au niveau organisation/entreprise pour un contrôle centralisé), documenté sur la page officielle Managing GitHub Actions settings for a repository. Trois réflexes avant de passer à autre chose :

• Vérifie la rétention actuellement configurée sur tes dépôts critiques — beaucoup d’équipes n’y ont jamais touché depuis la création du dépôt.
• Si tu as besoin de conserver une preuve d’exécution au-delà de 90 jours (audit SOC 2, exigence contractuelle), augmente la rétention jusqu’au plafond autorisé par ton organisation, ou exporte régulièrement les données vers un stockage externe via l’API Actions.
• Pour un dépôt public qui doit prouver sa conformité sur le long terme, ne compte plus sur la rétention native : archive toi-même les résultats de checks importants (par exemple via un job qui pousse un résumé signé vers un bucket ou un dépôt séparé).

FAQ

Puis-je récupérer des runs déjà supprimés par ce changement ?

Non. GitHub est catégorique : les enregistrements nettoyés ne sont pas restaurés, qu’ils aient été supprimés avant ou après le 1er octobre.

Ce changement affecte-t-il les workflows en cours d’exécution ?

Non, seuls les checks, runs et statuts déjà terminés et dépassant la période de rétention configurée sont concernés.

Un dépôt privé peut-il dépasser 90 jours de rétention ?

Oui, si l’organisation ou l’entreprise qui l’héberge autorise une limite plus élevée. Le plafond de 90 jours est strictement réservé aux dépôts publics.

Ce qu’il reste à faire

Si ton pipeline s’appuie déjà sur du caching pour accélérer les builds, pense à vérifier en même temps ta configuration cache-mode — les deux réglages touchent au même menu Actions et autant les revoir ensemble. Et si tu n’as pas encore activé les défenses anti-supply-chain sur tes workflows critiques, notre article sur le sujet reste d’actualité. Dans tous les cas, prends dix minutes cette semaine pour ouvrir les réglages Actions de tes dépôts les plus sensibles : la rétention par défaut ne correspond pas forcément à ce que ton équipe pense avoir configuré.