Le dossier .github est un petit répertoire magique que vous avez sûrement déjà croisé à la racine de vos dépôts préférés. Il est là, non pas pour faire joli ou pour planquer vos secrets de fabrication (pour ça, y'a les secrets GitHub, hein), mais plutôt pour centraliser plusieurs fichiers de configuration reconnus nativement par la plateforme.

C'est un peu le centre de commande de votre repo. Et le truc qui est fort, c'est que si vous avez une organisation avec 50 projets, vous pouvez même créer un dépôt public spécial nommé .github qui servira à fournir des fichiers de santé communautaire et des templates par défaut pour tous les dépôts de votre organisation qui n'ont pas déjà leurs propres fichiers équivalents.

Et comme ça, dès qu'un dépôt a quoi que ce soit dans son propre .github/ISSUE_TEMPLATE/, il ne prendra plus les templates par défaut de l'orga.

Pratique pour les grosses flemmasses comme vous quoi !

Les templates d'Issues et de PR pour structurer les échanges

On a tous reçu une issue qui dit juste "ça marche pas". C'est relou, ça fait perdre du temps et on a envie de répondre par un gif de chat qui boude.

Alors pour éviter ça, créez un dossier .github/ISSUE_TEMPLATE/. Vous pouvez y coller des fichiers Markdown ou YAML pour encourager les gens à donner les infos de base (version de l'OS, étapes pour reproduire, etc.). Et faites pareil pour les Pull Requests avec un fichier PULL_REQUEST_TEMPLATE.md (à la racine, dans docs/, ou dans .github/, selon votre tambouille).

En gros, ça vous permet de guider vos contributeurs pour qu'ils ne fassent pas n'importe quoi.

GitHub Actions pour détecter les régressions

C'est LE grand classique !

Dans .github/workflows/, vous balancez vos fichiers YAML pour automatiser vos tests, votre linting ou vos déploiements. Bien sûr, pour vraiment ne pas "casser la prod", il faudra coupler ça à des règles de protection de branche (status checks requis) pour bloquer les merges si les tests échouent.

D'ailleurs, si vous voulez tester vos actions sans attendre la file d'attente des runners GitHub, je vous avais parlé de Wrkflw pour tester ça en local . C'est un outil tiers bien pratique pour valider vos workflows sur votre machine.

Les fichiers de "Santé Communautaire"

Si vous voulez que votre projet open source ressemble à autre chose qu'un champ de bataille au petit matin, il faut poser des règles.

GitHub reconnaît automatiquement des fichiers comme CODE_OF_CONDUCT.md, CONTRIBUTING.md ou même FUNDING.yml pour gratter quelques pièces pour votre café ;). Ce sont des fichiers qui aident à dire aux gens comment se comporter et comment vous aider efficacement sans avoir à surveiller votre voisin.

Guider Copilot avec des instructions sur mesure

C'est la petite nouveauté qui vous permet d'ajouter un fichier .github/copilot-instructions.md avec à l'intérieur, une liste de vos standards de code, vos libs préférées ou vos conventions de nommage.

Comme ça, hop, Copilot tiendra compte de ces instructions pour ses suggestions (même s'il garde parfois son petit caractère, hihi). Et vous pouvez même aller plus loin avec des fichiers NAME.instructions.md dans .github/instructions/ qui ciblent des dossiers specifiques via des patterns glob... à condition de mettre un frontmatter applyTo: au début, sinon Copilot les ignorera gentiment...

C'est parfait pour garder un code propre.

CODEOWNERS et Dependabot

Enfin, pour les projets qui commencent à prendre de l'ampleur, le fichier CODEOWNERS (placé dans .github/, ou à la racine, ou dans docs/... GitHub prend celui de .github/ en premier s'il y en a plusieurs) permet de définir qui est responsable de quelle partie du code. Dès qu'une PR touche à un fichier sensible, GitHub demande automatiquement la review aux bonnes personnes.

Et n'oubliez pas .github/dependabot.yml pour que l'outil vous ouvre des pull requests dès qu'une dépendance est à la bourre.

On automatise le bien relou pour ne garder que du criss de fun !

Voilà les amis, si vous aimez bidouiller vos dépôts pour qu'ils tournent tout seuls ou presque et garder un semblant d'organisation, ce dossier .github sera votre meilleur poto !

Source

Dans un article publié le 18 février 2026, le média britannique The Register revient sur l'exaspération de nombreux modérateurs open source confrontés au fait de devoir vérifier et corriger des demandes de modification de code boostées par IA. Une gronde qui pousse bon nombre de projets à adopter des mesures de précaution.

Dans un article publié le 18 février 2026, le média britannique The Register revient sur l'exaspération de nombreux modérateurs open source confrontés au fait de devoir vérifier et corriger des demandes de modification de code boostées par IA. Une gronde qui pousse bon nombre de projets à adopter des mesures de précaution.

Bonne nouvelle pour tous les dev qui n'ont pas peur de l'IA : GitHub vient de sortir gh-aw, une extension CLI qui permet d’écrire des workflows agentiques… en markdown. Au chiotte le YAML à rallonge pour vos pipelines CI/CD, vous rédigez vos instructions en langage naturel et c'est une IA (Copilot, Claude ou Codex au choix) qui se charge de les exécuter dans GitHub Actions.

En gros, vous décrivez ce que vous voulez dans un fichier .md, genre"em>fais-moi un rapport quotidien des issues ouvertes" ou "refactorise les fonctions trop longues", et l'agent s'en occupe. Il analyse le contexte de votre dépôt, prend des décisions et livre le résultat sous forme de pull request. Par contre, attention, si votre prompt dans le fichier .md est trop vague genre "améliore le code ", l'agent risque de partir dans tous les sens et vous pondre une PR de 200 fichiers. Faut être précis dans vos instructions, sinon c'est la loterie.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/gh-aw-github-agents-ia-pipelines/gh-aw-github-agents-ia-pipelines-1.mp4">lien vers la vidéo</a>.