{"id":2363,"date":"2026-02-22T10:30:00","date_gmt":"2026-02-22T09:30:00","guid":{"rendered":"https:\/\/elearningsamba.com\/index.php\/automatisez-vos-repos-github-avec-github\/"},"modified":"2026-02-22T10:30:00","modified_gmt":"2026-02-22T09:30:00","slug":"automatisez-vos-repos-github-avec-github","status":"publish","type":"page","link":"https:\/\/elearningsamba.com\/index.php\/automatisez-vos-repos-github-avec-github\/","title":{"rendered":"Automatisez vos repos GitHub avec .github"},"content":{"rendered":"

Le dossier .github<\/code> est un petit r\u00e9pertoire magique que vous avez s\u00fbrement d\u00e9j\u00e0 crois\u00e9 \u00e0 la racine de vos d\u00e9p\u00f4ts pr\u00e9f\u00e9r\u00e9s. Il est l\u00e0, non pas pour faire joli ou pour planquer vos secrets de fabrication (pour \u00e7a, y’a les secrets GitHub, hein), mais plut\u00f4t pour centraliser plusieurs fichiers de configuration reconnus nativement par la plateforme.<\/p>\n

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\u00eame cr\u00e9er un d\u00e9p\u00f4t public sp\u00e9cial nomm\u00e9 .github<\/code> qui servira \u00e0 fournir des fichiers de sant\u00e9 communautaire et des templates par d\u00e9faut pour tous les d\u00e9p\u00f4ts de votre organisation qui n’ont pas d\u00e9j\u00e0 leurs propres fichiers \u00e9quivalents.<\/p>\n

Et comme \u00e7a, d\u00e8s qu’un d\u00e9p\u00f4t a quoi que ce soit dans son propre .github\/ISSUE_TEMPLATE\/<\/code>, il ne prendra plus les templates par d\u00e9faut de l’orga.<\/p>\n

Pratique pour les grosses flemmasses comme vous quoi !<\/p>\n

Les templates d’Issues et de PR pour structurer les \u00e9changes<\/h2>\nOn a tous re\u00e7u une issue qui dit juste “\u00e7a marche pas”. C’est relou, \u00e7a fait perdre du temps et on a envie de r\u00e9pondre par un gif de chat qui boude.<\/p>\n Alors pour \u00e9viter \u00e7a, cr\u00e9ez un dossier .github\/ISSUE_TEMPLATE\/<\/code>. Vous pouvez y coller des fichiers Markdown ou YAML pour encourager les gens \u00e0 donner les infos de base (version de l’OS, \u00e9tapes pour reproduire, etc.). Et faites pareil pour les Pull Requests avec un fichier PULL_REQUEST_TEMPLATE.md<\/code> (\u00e0 la racine, dans docs\/<\/code>, ou dans .github\/<\/code>, selon votre tambouille).<\/p>\n En gros, \u00e7a vous permet de guider vos contributeurs pour qu’ils ne fassent pas n’importe quoi.<\/p>\n GitHub Actions pour d\u00e9tecter les r\u00e9gressions<\/h2>\nC’est LE grand classique !<\/p>\n Dans .github\/workflows\/<\/code>, vous balancez vos fichiers YAML pour automatiser vos tests, votre linting ou vos d\u00e9ploiements. Bien s\u00fbr, pour vraiment ne pas “casser la prod”, il faudra coupler \u00e7a \u00e0 des r\u00e8gles de protection de branche (status checks requis) pour bloquer les merges si les tests \u00e9chouent.<\/p>\n D’ailleurs, si vous voulez tester vos actions sans attendre la file d’attente des runners GitHub, je vous avais parl\u00e9 de \nWrkflw pour tester \u00e7a en local<\/a> \n. C’est un outil tiers bien pratique pour valider vos workflows sur votre machine.<\/p>\n Les fichiers de “Sant\u00e9 Communautaire”<\/h2>\nSi vous voulez que votre projet open source ressemble \u00e0 autre chose qu’un champ de bataille au petit matin, il faut poser des r\u00e8gles.<\/p>\n GitHub reconna\u00eet automatiquement des fichiers comme CODE_OF_CONDUCT.md<\/code>, CONTRIBUTING.md<\/code> ou m\u00eame FUNDING.yml<\/code> pour gratter quelques pi\u00e8ces pour votre caf\u00e9 ;). Ce sont des fichiers qui aident \u00e0 dire aux gens comment se comporter et comment vous aider efficacement sans avoir \u00e0 surveiller votre voisin.<\/p>\nGuider Copilot avec des instructions sur mesure<\/h2>\nC’est la petite nouveaut\u00e9 qui vous permet d’ajouter un fichier .github\/copilot-instructions.md<\/code> avec \u00e0 l’int\u00e9rieur, une liste de vos standards de code, vos libs pr\u00e9f\u00e9r\u00e9es ou vos conventions de nommage.<\/p>\n Comme \u00e7a, hop, Copilot tiendra compte de ces instructions pour ses suggestions (m\u00eame s’il garde parfois son petit caract\u00e8re, hihi). Et vous pouvez m\u00eame aller plus loin avec des fichiers NAME.instructions.md<\/code> dans .github\/instructions\/<\/code> qui ciblent des dossiers specifiques via des patterns glob… \u00e0 condition de mettre un frontmatter applyTo:<\/code> au d\u00e9but, sinon Copilot les ignorera gentiment…<\/p>\n C’est parfait pour garder un code propre.<\/p>\nCODEOWNERS et Dependabot<\/h2>\nEnfin, pour les projets qui commencent \u00e0 prendre de l’ampleur, le fichier CODEOWNERS<\/code> (plac\u00e9 dans .github\/<\/code>, ou \u00e0 la racine, ou dans docs\/<\/code>… GitHub prend celui de .github\/<\/code> en premier s’il y en a plusieurs) permet de d\u00e9finir qui est responsable de quelle partie du code. D\u00e8s qu’une PR touche \u00e0 un fichier sensible, GitHub demande automatiquement la review aux bonnes personnes.<\/p>\n Et n’oubliez pas .github\/dependabot.yml<\/code> pour que l’outil vous ouvre des pull requests d\u00e8s qu’une d\u00e9pendance est \u00e0 la bourre.<\/p>\n On automatise le bien relou pour ne garder que du criss de fun !<\/p>\n Voil\u00e0 les amis, si vous aimez bidouiller vos d\u00e9p\u00f4ts pour qu’ils tournent tout seuls ou presque et garder un semblant d’organisation, ce dossier .github sera votre meilleur poto !<\/p>\n\nSource<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Le dossier .github est un petit r\u00e9pertoire magique que vous avez s\u00fbrement d\u00e9j\u00e0 crois\u00e9 \u00e0 la racine de vos d\u00e9p\u00f4ts pr\u00e9f\u00e9r\u00e9s. Il est l\u00e0, non pas pour faire joli ou pour planquer vos secrets de fabrication (pour \u00e7a, y’a les secrets GitHub, hein), mais plut\u00f4t 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\u00eame cr\u00e9er un d\u00e9p\u00f4t public sp\u00e9cial nomm\u00e9 .github qui servira \u00e0 fournir des fichiers de sant\u00e9 communautaire et des templates par d\u00e9faut pour tous les d\u00e9p\u00f4ts de votre organisation qui n’ont pas d\u00e9j\u00e0 leurs propres fichiers \u00e9quivalents. Et comme \u00e7a, d\u00e8s qu’un d\u00e9p\u00f4t a quoi que ce soit dans son propre .github\/ISSUE_TEMPLATE\/, il ne prendra plus les templates par d\u00e9faut de l’orga. Pratique pour les grosses flemmasses comme vous quoi ! Les templates d’Issues et de PR pour structurer les \u00e9changes On a tous re\u00e7u une issue qui dit juste “\u00e7a marche pas”. C’est relou, \u00e7a fait perdre du temps et on a envie de r\u00e9pondre par un gif de chat qui boude. Alors pour \u00e9viter \u00e7a, cr\u00e9ez un dossier .github\/ISSUE_TEMPLATE\/. Vous pouvez y coller des fichiers Markdown ou YAML pour encourager les gens \u00e0 donner les infos de base (version de l’OS, \u00e9tapes pour reproduire, etc.). Et faites pareil pour les Pull Requests avec un fichier PULL_REQUEST_TEMPLATE.md (\u00e0 la racine, dans docs\/, ou dans .github\/, selon votre tambouille). En gros, \u00e7a vous permet de guider vos contributeurs pour qu’ils ne fassent pas n’importe quoi. GitHub Actions pour d\u00e9tecter les r\u00e9gressions C’est LE grand classique ! Dans .github\/workflows\/, vous balancez vos fichiers YAML pour automatiser vos tests, votre linting ou vos d\u00e9ploiements. Bien s\u00fbr, pour vraiment ne pas “casser la prod”, il faudra coupler \u00e7a \u00e0 des r\u00e8gles de protection de branche (status checks requis) pour bloquer les merges si les tests \u00e9chouent. D’ailleurs, si vous voulez tester vos actions sans attendre la file d’attente des runners GitHub, je vous avais parl\u00e9 de Wrkflw pour tester \u00e7a en local . C’est un outil tiers bien pratique pour valider vos workflows sur votre machine. Les fichiers de “Sant\u00e9 Communautaire” Si vous voulez que votre projet open source ressemble \u00e0 autre chose qu’un champ de bataille au petit matin, il faut poser des r\u00e8gles. GitHub reconna\u00eet automatiquement des fichiers comme CODE_OF_CONDUCT.md, CONTRIBUTING.md ou m\u00eame FUNDING.yml pour gratter quelques pi\u00e8ces pour votre caf\u00e9 ;). Ce sont des fichiers qui aident \u00e0 dire aux gens comment se comporter et comment vous aider efficacement sans avoir \u00e0 surveiller votre voisin. Guider Copilot avec des instructions sur mesure C’est la petite nouveaut\u00e9 qui vous permet d’ajouter un fichier .github\/copilot-instructions.md avec \u00e0 l’int\u00e9rieur, une liste de vos standards de code, vos libs pr\u00e9f\u00e9r\u00e9es ou vos conventions de nommage. Comme \u00e7a, hop, Copilot tiendra compte de ces instructions pour ses suggestions (m\u00eame s’il garde parfois son petit caract\u00e8re, hihi). Et vous pouvez m\u00eame aller plus loin avec des fichiers NAME.instructions.md dans .github\/instructions\/ qui ciblent des dossiers specifiques via des patterns glob… \u00e0 condition de mettre un frontmatter applyTo: au d\u00e9but, sinon Copilot les ignorera gentiment… C’est parfait pour garder un code propre. CODEOWNERS et Dependabot Enfin, pour les projets qui commencent \u00e0 prendre de l’ampleur, le fichier CODEOWNERS (plac\u00e9 dans .github\/, ou \u00e0 la racine, ou dans docs\/… GitHub prend celui de .github\/ en premier s’il y en a plusieurs) permet de d\u00e9finir qui est responsable de quelle partie du code. D\u00e8s qu’une PR touche \u00e0 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\u00e8s qu’une d\u00e9pendance est \u00e0 la bourre. On automatise le bien relou pour ne garder que du criss de fun ! Voil\u00e0 les amis, si vous aimez bidouiller vos d\u00e9p\u00f4ts pour qu’ils tournent tout seuls ou presque et garder un semblant d’organisation, ce dossier .github sera votre meilleur poto ! Source<\/p>\n","protected":false},"author":1,"featured_media":2364,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"give_campaign_id":0,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_kadence_starter_templates_imported_post":false,"footnotes":""},"class_list":["post-2363","page","type-page","status-publish","has-post-thumbnail","hentry"],"campaignId":"","_links":{"self":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages\/2363","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/comments?post=2363"}],"version-history":[{"count":0,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages\/2363\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/media\/2364"}],"wp:attachment":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/media?parent=2363"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}