Résumé

  • GitHub décrit l’archivage comme un passage du dépôt en lecture seule et comme l’indication qu’il n’est plus activement maintenu; l’opération est réversible par désarchivage.
  • Cette information concerne les surfaces du dépôt dans GitHub, non l’artefact, l’usage ou la décision d’un consommateur donné.
  • Une observation d’archive et une décision locale de retrait doivent donc rester deux écritures attribuables.

Le badge décrit un dépôt, pas une dépendance

Un dépôt archivé donne une impression de finalité. Le code, les issues, les versions et les tags restent pourtant visibles, tandis que l’interface annonce un état qui paraît facile à résumer par « terminé ». Cette formule est trop large. Elle confond le dépôt identifié par GitHub avec les multiples objets qui peuvent provenir de lui et avec les systèmes qui les emploient.

La page officielle d’archivage des dépôts est plus précise. GitHub dit que l’archive met le dépôt en lecture seule pour tous et indique qu’il n’est plus activement maintenu. Issues, pull requests, code, labels, jalons, projets, wiki, releases, commits, tags, branches, réactions, alertes d’analyse, commentaires et permissions deviennent en lecture seule. Pour changer le dépôt, il faut le désarchiver.

Cette borne est importante. Elle ne prouve pas qu’une équipe consommatrice a supprimé un paquet, qu’une image de production a disparu, qu’un miroir interne a changé ou qu’une version donnée n’existe plus. Elle ne prouve pas non plus une vulnérabilité, une interruption ou une obligation de remplacement. L’archive est une observation sur une surface de plateforme et sur le signal de maintenance affiché par son propriétaire. Elle n’est pas l’inventaire d’actifs d’autrui.

Une décision locale commence avec un objet local

Le consommateur peut dépendre d’un paquet publié, d’un commit fixé, d’un artefact recompilé, d’une copie embarquée ou d’une dépendance transitive. Pour chacun, les questions pertinentes sont différentes : quelle version est réellement résolue, dans quel environnement, avec quelles permissions, quel propriétaire, quelle alternative et quel moment de revue? Aucune de ces réponses ne figure dans l’état d’archive.

Un signal public peut donc devenir un déclencheur, mais non une disposition. L’équipe peut constater qu’aucun de ses actifs ne correspond au dépôt. Elle peut documenter un remplacement, accepter temporairement un usage limité, isoler le composant, surveiller une condition ou ouvrir une revue. Elle peut aussi ne pas encore avoir de conclusion. Faire passer l’archive directement au statut « retiré » efface la personne qui a choisi et les faits qu’elle a examinés.

GitHub distingue lui-même l’archive d’autres actes. Le transfert d’un dépôt modifie l’administration par un nouveau propriétaire. Le changement de visibilité a ses propres conséquences pour les forks et l’accès. Les contrôles peuvent se succéder; ils ne se remplacent pas, et aucun ne tranche l’usage d’un artefact chez un tiers.

Deux traces plutôt qu’un verdict emprunté

La première trace doit contenir la référence exacte du dépôt, l’état archive ou désarchive, l’heure d’observation et la source. Elle doit dire ce que GitHub affirme et ce qu’elle ne permet pas d’inférer. Un désarchivage ultérieur ajoute une nouvelle observation; il n’annule pas silencieusement l’ancienne.

La seconde appartient au consommateur. Elle lie le paquet, commit ou digest considéré à son contexte d’usage, à un responsable, aux preuves consultées, à l’action — ou l’absence d’action — et à une date ou un déclencheur de réexamen. La séparation ne fabrique pas une procédure universelle. Elle empêche seulement une étiquette pratique de devenir une décision sans propriétaire.

Sources

  1. GitHub Docs — Archiving repositories
  2. GitHub Docs — Transferring a repository
  3. GitHub Docs — Setting repository visibility