GitHub aligne la rétention des checks et des runs Actions sur 90 jours dès le 1er octobre
À partir du 1er octobre 2026, GitHub applique à la rétention des checks, des workflow runs et des statuses le même réglage que celui des artefacts et des logs, soit 90 jours par défaut au lieu de plus de 400. Les équipes qui s’appuient sur cet historique doivent vérifier leur réglage et exporter ce qu’elles veulent conserver.
27 août 2026. GitHub annonce le changement dans son changelog. 1er octobre 2026. La nouvelle rétention entre en vigueur. 90 jours. C’est la fenêtre par défaut qui remplace un historique de plus de 400 jours. En une annonce, une partie de la mémoire opérationnelle des pipelines CI/CD passe de l’implicite au réglable — et ce qui n’est pas réglé sera purgé.
Ce qui change exactement
Jusqu’ici, les checks, les workflow runs et les statuses de GitHub Actions étaient conservés pendant plus de 400 jours, quel que soit le réglage de rétention du dépôt. Ce réglage ne gouvernait que les artefacts et les logs.
À partir du 1er octobre 2026, les cinq éléments sont soumis à la même règle : checks, workflow runs, statuses, artefacts et logs. Ils seront automatiquement nettoyés une fois la période configurée dépassée, avec une valeur par défaut de 90 jours.
L’étiquette de l’interface change en conséquence — elle devient « Check, workflow run, status, artifact and log retention » — mais c’est le comportement qui compte. Un historique que les équipes tenaient pour acquis va désormais dépendre d’un paramètre que beaucoup n’ont jamais ouvert.
Ce qui ne change pas, et pourquoi c’est important
Trois garde-fous encadrent la purge. D’abord, le changement n’est pas rétroactif : ajuster son réglage ne restaure pas des données déjà évincées. Ensuite, un dépôt ne peut relever sa rétention qu’à hauteur du plafond fixé au niveau de l’organisation ou de l’entreprise. Enfin, pour les dépôts publics, le maximum est de 90 jours, aligné sur la limite déjà en vigueur pour les artefacts et les logs.
Ces trois points dessinent le vrai enjeu. Un dépôt public ne pourra jamais conserver ses checks au-delà de 90 jours, quoi qu’on fasse. Un dépôt privé ne pourra pas non plus contourner le plafond de son organisation. La marge de manœuvre se situe entre la valeur par défaut et le plafond — pas au-delà.
Pourquoi GitHub change maintenant
La motivation officielle tient en une phrase du changelog : réduire la quantité de données obsolètes stockées dans GitHub Actions pour garder les checks, les workflow runs et les statuses « rapides et fiables pour tout le monde ». En clair, c’est un arbitrage d’infrastructure — des millions de dépôts conservent des centaines de jours d’historique que presque personne ne relit, et ce stockage a un coût réel.
Le choix de la date — un 1er octobre — n’est pas anodin. Il laisse un peu plus d’un mois aux organisations pour ajuster leurs réglages, ce qui est cohérent avec la politique de GitHub d’annoncer les changements de comportement avant de les appliquer. Le précédent des artefacts et des logs, déjà soumis à cette rétention, a servi de banc d’essai.
Ce qui change de nature, c’est l’extension de la règle à des données que les équipes traitaient comme permanentes. Là où les artefacts sont des fichiers de build que l’on sait éphémères, les checks et les runs sont perçus comme l’historique vivant du projet. La transition de l’un à l’autre est le vrai sujet.
L’enjeu d’audit et d’investigation
Pour une équipe plateforme, un workflow run n’est pas qu’un écran de suivi. C’est une trace : qui a déclenché quoi, avec quel commit, quel résultat, quel artefact. Les équipes s’en servent pour reconstituer un incident, prouver une conformité, ou répondre à un audit.
Le passage de 400 jours à 90 jours compresse cette mémoire d’un facteur supérieur à quatre. Une investigation qui remonte à six mois ne trouvera plus l’historique des checks et des statuses — seuls les artefacts et logs subsisteront, s’ils sont eux-mêmes encore dans la fenêtre.
La distinction entre métadonnées et contenu compte ici. GitHub précise que les métadonnées des checks, runs et statuses ne sont pas facturées, mais que les artefacts et logs associés le sont. La donnée la plus utile à l’audit — le déroulé des exécutions — est précisément celle qui va s’évaporer gratuitement.
L’enjeu financier
La facturation suit une logique simple : baisser la rétention supprime les artefacts et logs plus tôt, ce qui réduit le stockage facturé. L’augmenter les conserve plus longtemps et peut accroître la facture.
Le piège est l’asymétrie. Les métadonnées de checks et de runs, elles, ne coûtent rien à conserver — mais elles seront désormais purgées au même rythme que les artefacts payants. Autrement dit, la donnée gratuite disparaît pour économiser la donnée payante. C’est un arbitrage que chaque équipe doit poser consciemment plutôt que le subir par défaut.
La rétention n’est pas une sauvegarde
Il faut dissiper une confusion fréquente. La purge des checks et des runs ne supprime ni le code, ni les commits, ni les tags : le dépôt lui-même reste intact. Ce qui disparaît, c’est la trace d’exécution — le fait qu’un commit précis a produit un résultat précis, à une date donnée, avec tel artefact.
Cette distinction a une conséquence directe pour l’archivage. Si une équipe a besoin de prouver, des mois plus tard, qu’un build a été validé ou qu’un test est passé, elle doit exporter cette trace elle-même. Les journaux de runs, les rapports de tests, les métadonnées de déploiement : tout ce qui n’est pas versionné dans le dépôt relève désormais d’une politique d’export explicite.
En pratique, cela passe par l’API GitHub Actions ou la CLI gh pour lister et exporter les runs avant l’échéance, ou par un relais vers un système d’observabilité qui conserve son propre historique. Ceux qui découvrent le besoin après le 1er octobre ne pourront plus rien récupérer.
Que faire avant le 1er octobre
Pour la plupart des dépôts, aucune action n’est requise : le nettoyage suivra le réglage déjà configuré. Mais « la plupart » n’est pas « tous ».
Vérifiez d’abord le réglage de rétention du dépôt, de l’organisation et de l’entreprise. Confirmez qu’il reflète bien la durée pendant laquelle vous avez besoin des checks, runs et statuses — pas seulement des artefacts.
Ensuite, augmentez la période si nécessaire, dans la limite des plafonds. Gardez à l’esprit qu’une rétention plus longue maintient aussi les artefacts et logs plus longtemps, avec un impact possible sur la facturation.
Enfin, exportez ou archivez tout ce que vous devez conserver au-delà de la fenêtre. Les éléments plus anciens seront supprimés automatiquement une fois le changement effectif, et rien ne pourra les restaurer.
Le réglage se pilote à trois niveaux — dépôt, organisation, entreprise — et le plus efficace est de le poser une fois au niveau de l’organisation, puis de n’ajuster que les dépôts qui font exception. Un réglage hérité vaut mieux qu’une décision par dépôt, oubliée à la première rotation d’équipe.
Verdict
Si vos pipelines ne servent qu’à construire et déployer, ne touchez à rien : la purge à 90 jours vous fera probablement économiser du stockage sans coût opérationnel.
Si vous dépendez de l’historique des checks et des runs pour l’audit, la conformité ou l’investigation d’incident, agissez avant le 1er octobre 2026 : relevez la rétention jusqu’au plafond autorisé là où c’est nécessaire, et mettez en place un export régulier de ce que vous devez garder au-delà. Une trace CI/CD qui n’a jamais été jugée précieuse devient, du jour au lendemain, une trace qui n’existe plus.