Configurer la GitHub App

Une GitHub App est la méthode recommandée par GitHub pour donner à un service un accès limité à un dépôt. Contrairement à un jeton d’accès personnel, elle a sa propre identité (pullpress[bot]), ses permissions sont fixes et visibles, et vous pouvez la limiter exactement aux dépôts que vous choisissez.

Les permissions demandées

Pendant l’installation, GitHub vous montre la liste complète des permissions. Elle est volontairement courte :

• Contents : lecture et écritureLire vos fichiers de contenu et commiter les modifications des rédacteurs sur des branches.
• Pull requests : lecture et écritureOuvrir, mettre à jour et étiqueter les pull requests soumises par les rédacteurs.
• Metadata : lectureInformations de base sur le dépôt (nom, branche par défaut). Obligatoire pour toute GitHub App.
• Organization members : lectureSert uniquement à vérifier si la personne qui connecte est propriétaire de votre organisation GitHub, ce qui lui permet de retirer une installation à un espace de travail qui ne devrait pas l’avoir.
• Checks : lecture (facultatif)Permet au tableau de bord d’indiquer si votre site est en cours de build ou en ligne après une modification. Sans elle, tout le reste fonctionne pareil.
• Workflows, Actions, paramètres, secretsExplicitement non demandés. PullPress ne peut pas modifier votre CI, les paramètres du dépôt, les webhooks ni les secrets.

Installer sur un seul dépôt

• Dans votre tableau de bord PullPress, choisissez Connecter un site web (ou Connecter un site sur la page Sites & GitHub). Vous êtes envoyé sur l’écran d’installation de GitHub.
• Choisissez le compte ou l’organisation propriétaire du dépôt, puis Only select repositories et sélectionnez le dépôt de votre site. Vous pourrez toujours en ajouter d’autres plus tard.
• Vérifiez les permissions et confirmez. GitHub vous demande d’autoriser PullPress pour votre compte GitHub et vous redirige.

C’est par cette étape d’autorisation que PullPress vérifie que vous avez vraiment accès à l’installation avant de la lier à votre espace de travail : il demande à GitHub quelles installations de l’App votre compte GitHub peut atteindre et n’accepte que celles-là. Personne ne peut rattacher vos dépôts à son espace en devinant un numéro d’installation, et une installation déjà connectée à un autre espace par un autre utilisateur GitHub est refusée.

L’accès à une installation n’est pas l’accès à chacun de ses dépôts : PullPress demande donc aussi à GitHub sur quels dépôts votre compte peut pousser. Seuls ceux-là sont proposés quand vous ajoutez un site, et la vérification est refaite sur le serveur. Elle reste valable une semaine ; ensuite, un clic sur Actualiser mon accès aux dépôts la refait auprès de GitHub.

Une fois qu’un site existe, il continue de fonctionner via l’App, même si la personne qui a connecté GitHub quitte ensuite votre organisation. Tous les 180 jours, PullPress demande donc à un administrateur de l’espace de reconfirmer la connexion : la page Sites affiche À reconfirmer avant le… deux semaines à l’avance, les propriétaires et administrateurs reçoivent un e-mail, et Vérifier avec GitHub à côté de l’installation règle cela en un clic. Ce n’est qu’un rappel : l’édition et la publication ne sont jamais bloquées.

De retour dans PullPress, l’écran de connexion confirme d’abord quel compte l’installation couvre et combien de dépôts elle atteint, avec un lien direct pour modifier l’installation sur GitHub si elle a atterri sur le mauvais compte ou les mauvais dépôts. Si vous interrompez le parcours GitHub à mi-chemin, PullPress affiche une note indiquant que l’installation n’a pas été terminée, avec un lien pour réessayer, au lieu d’échouer en silence.

Les administrateurs d’une organisation peuvent aussi installer l’App pour un collègue. Celui-ci ouvre alors l’écran de connexion (ou la page Sites) et choisit Vérifier avec GitHub (ou Lier une installation existante) : GitHub confirme son accès et l’installation est prête. Si votre compte GitHub atteint plusieurs installations, vous choisissez celle que cet espace doit utiliser ; PullPress ne les connecte jamais toutes à la fois. Les installations connectées avant l’existence de cette vérification demandent la même vérification unique avant qu’on puisse y ajouter de nouveaux sites.

Si un membre de l’organisation demande l’App au lieu de l’installer, PullPress vous indique que la demande attend un propriétaire de l’organisation ; une fois approuvée, utilisez Lier une installation existante.

Déconnecter et reprendre

Les propriétaires d’un espace peuvent Déconnecter une installation sur la page Sites dès qu’aucun site actif ne l’utilise. Rien ne change sur GitHub.

Si un autre espace PullPress détient une installation sur votre compte ou organisation GitHub, un propriétaire de ce compte peut la déplacer vers son propre espace (en tant que propriétaire d’un espace PullPress ; les administrateurs de l’espace voient l’option mais ont besoin d’un propriétaire pour confirmer) : GitHub confirme que cette personne est propriétaire, les sites de l’autre espace sur cette installation sont archivés (lecture seule) et ses propriétaires reçoivent un e-mail. Les déconnexions comme les reprises sont consignées dans le journal de l’espace de travail.

Comment une installation devient un site

Un dépôt connecté devient un site dans PullPress. Le site lit son modèle de contenu dans le pullpress.config.yml du dépôt, et chaque rédacteur que vous invitez est invité précisément sur ce site. Les agences avec de nombreux dépôts clients ont un site par dépôt, tous visibles dans le tableau de bord multisite, chacun avec ses rédacteurs et ses rôles.

Notes de sécurité

• Chemins autorisés. Les modifications des rédacteurs ne sont écrites que dans les dossiers déclarés par votre configuration : dossiers de collections et dossier des médias. Au-delà, PullPress n’écrit que deux fichiers à lui : son pullpress.config.yml (quand un administrateur met en place ou modifie la configuration) et, si vous l’utilisez, un llms.txt à la racine du dépôt. Les changements de configuration et l’entretien automatique d’un llms.txt existant sur les sites en publication directe sont commités directement sur votre branche par défaut ; le bouton manuel « Mettre à jour llms.txt » sur les autres sites passe par la relecture. Tout le reste, y compris .github/, est refusé.
• Aucun jeton dans le navigateur. Les navigateurs des rédacteurs ne parlent qu’à PullPress. Les identifiants GitHub sont des jetons d’installation de courte durée qui existent côté serveur et ne sont jamais envoyés au client. L’autorisation GitHub utilisée pour vérifier l’accès à la connexion utilise PKCE et est révoquée dès la fin de la vérification ; PullPress ne conserve aucun jeton d’utilisateur GitHub.
• Chaque modification est attribuable. Les commits et pull requests sont créés par pullpress[bot] et crédités au rédacteur qui les a faits, pour que votre historique Git garde son sens. Par défaut, l’auteur est le nom du rédacteur avec une adresse no-reply pseudonyme (id+name@users.noreply.…), donc les adresses e-mail ne finissent jamais dans l’historique d’un dépôt public. Un administrateur du site peut passer aux vraies adresses sous Paramètres du site → Utiliser les vraies adresses e-mail des rédacteurs dans l’historique Git.
• Révocable en un clic. Désinstallez l’App depuis vos paramètres GitHub quand vous voulez. L’accès cesse immédiatement et votre contenu reste exactement où il est. PullPress s’en aperçoit aussi : une installation désinstallée ou suspendue apparaît comme badge de statut dans la liste des sites et comme alerte sur le tableau de bord, et les administrateurs de l’espace reçoivent un e-mail en quelques minutes. Rien ne casse en silence.
• Les aperçus de branche construisent le contenu des rédacteurs. Les modifications en attente de relecture vivent sur leur propre branche. Si votre hébergeur construit un aperçu de chaque branche (Netlify, Vercel, Cloudflare Pages…), cet aperçu lance le build de votre site sur du contenu pas encore relu. PullPress empêche les rédacteurs d’ajouter des scripts ou du code MDX, et seules de vraies images JPG/PNG/WebP peuvent être envoyées. N’exposez tout de même pas de secrets de production aux builds d’aperçu ou de branche, et réservez les droits d’administrateur (qui peuvent ajouter du code) à des personnes de confiance.
• Les permissions manquantes sont nommées. S’il manque un jour à l’App une permission nécessaire (par exemple après une mise à jour des permissions que vous n’avez pas encore acceptée), l’erreur nomme exactement le scope manquant au lieu d’échouer de façon générique.

Étape suivante : décrivez votre contenu dans pullpress.config.yml, ou suivez toute la mise en place dans Premiers pas.