Ce qui est confirmé
GitHub va modifier la conservation des données de GitHub Actions à compter du 1er octobre 2026. Les checks, les exécutions de workflows et les statuts suivront alors le même réglage de rétention que les artefacts et les journaux. Pour une équipe qui s’appuie sur l’historique de CI/CD pour diagnostiquer un incident, la nouvelle mérite un contrôle avant la date d’entrée en vigueur.
Ce qui change dans GitHub Actions
Fait. Dans son changelog du 27 août 2026, GitHub annonce qu’à partir du 1er octobre 2026 les checks, les workflow runs et les statuses seront régis par le réglage de rétention GitHub Actions. Ce réglage contrôlait déjà la durée de conservation des artefacts et des logs.
Jusqu’ici, GitHub indique que les checks, les exécutions de workflows et les statuts étaient conservés plus de 400 jours, quelle que soit la configuration de rétention. Après le changement, ces éléments seront nettoyés lorsqu’ils dépasseront la période définie pour les artefacts et les journaux de ton dépôt, de ton organisation ou de ton entreprise.
Fait. GitHub annonce un réglage par défaut de 90 jours. L’intitulé dans l’interface doit devenir « Check, workflow run, status, artifact and log retention ». Le changement élargit donc le périmètre du réglage existant, il ne crée pas une nouvelle catégorie de conservation séparée.
Cette nuance compte. Une équipe pouvait jusqu’ici considérer que réduire la rétention des logs ne concernait que les fichiers et sorties associés à un job. Dès octobre, la même décision affectera aussi la durée pendant laquelle elle retrouve les contrôles, les runs et les statuts dans GitHub.
Pour suivre les autres annonces à venir, je te conseille de garder la page Actualités dans tes favoris. Si ton équipe utilise des agents dans son environnement de développement, l’article sur les plugins d’agents GitHub peut aussi compléter ta veille sans modifier cette annonce de rétention.
Les limites annoncées par GitHub
Fait. La rétention reste encadrée par des plafonds au niveau de l’organisation et de l’entreprise. Un dépôt ne peut augmenter sa durée de conservation qu’à hauteur du plafond qui lui est applicable. GitHub précise également que, pour les dépôts publics, la durée maximale des checks, workflows et statuts est de 90 jours, comme pour les artefacts et les logs.
Il ne faut donc pas lire cette annonce comme la promesse qu’un administrateur pourra fixer n’importe quelle durée depuis un dépôt isolé. La configuration pertinente peut se situer au niveau du dépôt, de l’organisation ou de l’entreprise, selon le périmètre qui encadre le projet.
Fait. Le changement n’est pas rétroactif. Selon GitHub, modifier un réglage de rétention ne restaurera pas des données déjà évincées par une politique de conservation. C’est une information importante pour un audit, un incident de production ou une analyse de tendance qui dépendrait de runs anciens.
Ce qui reste inconnu dans la source est tout aussi utile. GitHub ne détaille pas de calendrier de migration dépôt par dépôt. La source ne donne pas non plus de procédure de sauvegarde ni de recommandation de durée adaptée à chaque type de projet. Elle confirme le principe et la date, pas la politique interne que ton équipe doit choisir.
Ce que GitHub relie à la facturation
Fait. GitHub indique que les artefacts et les logs comptent dans le stockage facturable de GitHub Actions. Les métadonnées des checks, des workflow runs et des statuts ne sont pas facturées pour le stockage. GitHub ajoute qu’une conservation plus courte peut réduire l’usage de stockage facturable, tandis qu’une durée plus longue peut augmenter cet usage.
Cette formulation mérite de rester précise. La suppression plus rapide ne transforme pas automatiquement la facture d’une équipe donnée. La source présente une conséquence possible sur le stockage des artefacts et des logs, pas une économie chiffrée ni une garantie de baisse pour chaque compte.
Pourquoi c’est important
Analyse. Concrètement, la bonne question n’est pas seulement « combien de jours garder ? ». Il faut séparer trois besoins. Le premier est le diagnostic technique, qui peut exiger de consulter logs et artefacts. Le deuxième est la traçabilité opérationnelle, qui dépend des checks et des exécutions. Le troisième est la maîtrise du stockage facturable. À partir d’octobre, ces besoins seront davantage liés par le même réglage.
C’est aussi une raison de ne pas traiter GitHub comme une simple boîte noire de développeurs. Dans une stack SaaS ou no-code, les workflows automatisés finissent souvent par alimenter des déploiements, des tests ou des intégrations. Le guide pour automatiser son business donne un point d’entrée pour penser un workflow comme un processus à documenter, plutôt que comme une succession d’outils.
Vérifier son réglage avant le 1er octobre
Fait. GitHub indique que, dans la plupart des dépôts, aucune action n’est requise. L’entreprise recommande néanmoins de revoir le réglage de rétention avant le 1er octobre 2026 et de vérifier qu’il correspond à la période nécessaire pour conserver checks, runs et statuts. La durée peut être augmentée dans la limite des plafonds applicables.
Analyse. Voici la méthode que j’utiliserais, sans présumer de la configuration de ton compte :
- Identifier les dépôts qui servent à des produits, des intégrations ou des automatisations critiques.
- Vérifier le réglage de rétention effectif et le niveau qui le limite.
- Lister les usages réels de l’historique : diagnostic, conformité interne, support ou revue de déploiement.
- Comparer cette fenêtre de besoin avec la période configurée.
- Informer les personnes qui consultent des runs anciens après un incident.
Cette liste est une analyse opérationnelle, pas une procédure imposée par GitHub. Elle évite surtout une erreur simple : découvrir après la suppression qu’une équipe utilisait l’historique comme archive de fait. Le changement n’étant pas rétroactif, la restauration de données déjà évincées ne fait pas partie de ce que GitHub annonce.
Si tu construis des outils internes sans une équipe de développement dédiée, les ressources sur le no-code pour créer une app ou un site peuvent t’aider à cartographier les flux métier autour de ton dépôt. Pour la partie organisation, le dossier sur la gestion de projet et les outils offre un complément utile. Ces liens servent à structurer le travail, ils ne remplacent pas le réglage GitHub annoncé ici.
Ce que ça change pour toi
Analyse. Si tu es freelance, responsable ops ou entrepreneur SaaS, regarde d’abord la dépendance de ton activité à l’historique GitHub. Un workflow de déploiement peut sembler autonome jusqu’au jour où il échoue. À ce moment-là, les logs, les artefacts et la chronologie des checks deviennent des éléments de diagnostic.
La nouvelle règle rassemble ces éléments dans une même fenêtre de conservation. Cela simplifie la lecture de la politique, mais cela réduit aussi la marge d’erreur. Une durée courte peut être cohérente pour un projet de test. Elle peut être insuffisante pour un produit dont les incidents sont analysés plusieurs mois après leur apparition. C’est une analyse de contexte, la source ne fixe aucune durée universelle.
Je te conseille également de distinguer conservation et sauvegarde. La source parle du nettoyage automatique dans GitHub Actions après expiration de la période configurée. Elle ne décrit pas une stratégie de copie externe, ni une méthode de restauration. Si la conservation de preuves de build est un enjeu interne, il faut documenter ce besoin avant de modifier un réglage.
La même discipline s’applique à tes données marketing. Un CRM, une newsletter et un dépôt ne gardent pas forcément les mêmes éléments ni les mêmes durées. Tu peux revoir les bases dans le guide CRM : à quoi ça sert et comment choisir et dans celui pour choisir un outil d’email marketing. Le but n’est pas de tout conserver, mais de savoir précisément ce qui disparaît, quand et pourquoi.
Mon avis
Ce que cela change
Opinion. À mon avis, cette évolution est saine parce qu’elle rend la politique de rétention plus lisible. Je ne la traiterais pas comme un réglage de coût isolé. Je commencerais par les équipes qui dépendent de workflows anciens pour comprendre un incident, puis je vérifierais les plafonds applicables. Une politique écrite vaut mieux qu’une valeur choisie par défaut et oubliée.
FAQ
Quand GitHub change-t-il la rétention des checks et workflows Actions ?
GitHub annonce une entrée en vigueur le 1er octobre 2026. À partir de cette date, checks, workflow runs et statuts suivront le réglage de rétention GitHub Actions.
Combien de temps les données GitHub Actions sont-elles conservées par défaut ?
GitHub indique une durée de rétention par défaut de 90 jours pour le réglage concerné. Les plafonds applicables peuvent toutefois limiter la durée qu’un dépôt peut choisir.
Les anciens checks GitHub Actions seront-ils supprimés rétroactivement ?
Non. GitHub précise que le changement n’est pas rétroactif. Modifier le réglage ne restaure pas des données déjà évincées par une politique de rétention.
Les checks et statuts GitHub Actions augmentent-ils le stockage facturable ?
GitHub précise que les métadonnées des checks, workflow runs et statuts ne sont pas facturées pour le stockage. Les artefacts et les logs associés comptent, eux, dans le stockage facturable de GitHub Actions.
Que faut-il vérifier avant le 1er octobre 2026 ?
GitHub recommande de revoir le réglage de rétention au niveau du dépôt, de l’organisation ou de l’entreprise. Vérifie que sa durée correspond à la période pendant laquelle ton équipe doit retrouver checks, runs, statuts, artefacts et logs.
Information & avertissement
Cet article présente une annonce officielle de GitHub, publiée le 27 août 2026, et une analyse éditoriale. Il ne contient aucune offre commerciale validée ni lien affilié. Les réglages et plafonds à appliquer dépendent de la configuration de ton dépôt, de ton organisation ou de ton entreprise. Vérifie-les directement dans GitHub avant toute modification.
Sources et méthode
Les informations ont été vérifiées à partir des sources ci-dessous.
Les faits confirmés sont distingués des analyses et des limites encore ouvertes.
