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

On s'imagine souvent que les botnets, c'est un truc réservé aux PC vérolés de gamers qui téléchargent n'importe quoi. Sauf que non ! Votre box, votre routeur, ou n'importe quel appareil connecté de votre réseau domestique peut très bien faire partie d'un réseau de machines zombies sans que vous le sachiez.

C'est pour lutter contre ça que les gens de chez GreyNoise (une boîte spécialisée dans l'analyse des menaces réseau) ont lancé un outil gratuit pour vérifier en quelques secondes si votre IP a été repérée dans des activités de scanning suspectes. Ça s'appelle IP Check , vous allez sur le site, vous cliquez, et hop, le verdict est immédiat.

Quatre verdicts sont alors possibles. Soit votre IP est "Benign" et vous pouvez dormir tranquille. Soit elle est marquée "Malicious" ou "Suspicious", ce qui signifie qu'elle a été repérée en train de scanner Internet ou de participer à des activités louches. Soit c'est "Unknown", ce qui veut dire qu'elle n'a tout simplement jamais été vue par leurs sondes. L'outil indique aussi si votre IP appartient à un service connu (VPN, cloud, entreprise) grâce à leur base de données RIOT.

Le truc c'est que si votre IP est flaguée, l'outil vous affichera une timeline sur 90 jours, soit de quoi faire un petit diagnostic pour voir depuis quand une activité suspecte a été observée sur votre connexion. Parce que oui, le risque c'est que des botnets peuvent utiliser les connexions de particuliers comme relais pour leurs saloperies, et votre IP peut alors se retrouver sur des listes de réputation douteuse. Du coup vous vous tapez des CAPTCHA à répétition, des refus d'accès sur certains sites, ou des restrictions bizarres sur les services de streaming.

Et pour les amateurs de ligne de commande, y'a même une API JSON qui renvoie le statut de l'IP appelante !

curl -s https://check.labs.greynoise.io/api/v1/check | jq

Envie de gérer vos emails sans sortir de votre terminal ? Si vous êtes du genre à passer votre vie dans une console (genre pour les mecs comme moi quoi...), vous savez que les clients mails classiques sont souvent des usines à gaz qui mangent de la RAM pour rien.

C'est là qu'intervient Himalaya CLI .

C'est un client email écrit en Rust, donc autant vous dire que ça envoie du bois niveau rapidité et sécurité. L'idée, c'est de proposer un outil qui fait une seule chose mais qui la fait bien à savoir gérer vos courriers électroniques directement en ligne de commande, sans chichi.

Le truc cool, c'est qu'il est super polyvalent. Il gère le multi-compte sans broncher (Gmail, Outlook, iCloud, Protonmail...), supporte l'IMAP et le SMTP, mais peut aussi bosser avec des boîtes locales au format Maildir ou Notmuch. Pour les paranoïaques de la sécurité, le support PGP est de la partie pour chiffrer vos échanges, et il s'intègre même avec le trousseau de clés de votre OS pour stocker vos mots de passe proprement.

Pour l'installer en tant que user, c'est archi-simple :

curl -sSL https://raw.githubusercontent.com/pimalaya/himalaya/master/install.sh | PREFIX=~/.local sh

himalaya

Mark Zuckerberg a témoigné devant un tribunal de Los Angeles dans un procès important. Le sujet ? Les effets d'Instagram et Facebook sur la santé mentale des adolescents, avec près de 1 600 plaintes de familles et de districts scolaires américains regroupées dans cette affaire. Des documents internes accablants ont été dévoilés à l'audience.

Un procès hors norme

C'est devant la Cour supérieure de Los Angeles que le patron de Meta s'est présenté pour répondre aux accusations. Ce procès test doit déterminer si Instagram et Facebook ont contribué à dégrader la santé mentale des adolescents qui les utilisent. L'audience a démarré avec le témoignage de Kaley, une jeune femme de 20 ans qui a commencé à utiliser YouTube à 6 ans et Instagram à 9 ans. Son avocat, Mark Lanier, a déroulé devant le jury un collage de plus de 10 mètres composé de centaines de selfies qu'elle avait postés sur la plateforme. Dépression, dysmorphie corporelle, idées suicidaires : la jeune femme a décrit un parcours que des milliers d'autres familles affirment avoir vécu.

Des documents internes chocs

Et des preuves, il y en a : les avocats des plaignants ont sorti des documents internes de Meta qui datent de 2015. On y apprend qu'Instagram comptait à l'époque quatre millions d'utilisateurs de moins de 13 ans, soit environ 30 % des enfants américains de 10 à 12 ans. Un mémo de 2018 est encore plus direct : « Si on veut gagner gros avec les ados, il faut les attraper quand ils sont pré-ados ». Difficile d'être plus explicite.

Un autre document interne, daté de 2020, montre que les enfants de 11 ans avaient quatre fois plus de chances de revenir sur Facebook que les autres tranches d'âge. Zuckerberg a reconnu que les outils de protection avaient mis du temps à arriver. Il a même déclaré : « j'aurais aimé qu'on y arrive plus tôt » devant le tribunal. Sur les filtres de beauté, il a évoqué un compromis : les laisser disponibles sans les recommander.

Mais quelle défense pour Meta ?

Meta et Google, aussi visés dans cette procédure, défendent la même ligne : les réseaux sociaux ne causent pas directement de troubles psychologiques chez les jeunes. Probablement un peu embarrassés, les avocats de Meta expliquent que des dizaines de protections ont été mises en place ces dernières années, et aussi que la responsabilité incombe surtout aux parents. Le procès devrait durer six semaines, et d'autres dirigeants seront appelés à témoigner. L'enjeu dépasse clairement cette salle d'audience : si les plaignants obtiennent gain de cause, ça pourrait déclencher des milliers d'autres procédures à travers les États-Unis.

On a tous en tête un gosse qui passe ses journées sur TikTok ou Instagram, et ce procès met des visages et des chiffres sur ce problème qu'il est compliqué d'ignorer désormais. Le mémo « attrapez-les quand ils sont pré-ados » fait vraiment froid dans le dos. Reste à voir si ce procès changera quoi que ce soit, ou si dans cinq ans on en sera encore au même point, à regarder nos gamins scroller à l'infini en se disant que quelqu'un devrait faire quelque chose.

Article invité publié par Vincent Lautier .
Vous pouvez aussi me lire sur mon blog , sur Mac4ever , ou lire tous les tests que je publie ici, comme cette Webcam 4K , ou ce dock Thunderbolt 5 .

Aujourd'hui j'aimerais vous parler un peu de bidouille et plus particulièrement de domotique. Hé oui, si comme moi, vous en avez marre que tous vos objets connectés passent par des serveurs chinois (souvent à la sécurité douteuse) ou américains (souvent directement connecté à la NSA) pour vous dire qu'il fait 22°C dans votre salon, on va voir comment ensemble créer ses propres capteurs 100% locaux avec ESPHome .

ESPHome, c'est un framework open source qui transforme n'importe quel ESP32 ou ESP8266 en appareil connecté intelligent sans vous prendre la tête. Vous écrivez un petit fichier YAML, vous flashez la puce, et hop, vous avez un capteur qui cause directement avec Home Assistant. Comme ça y'a pas de cloud et encore moins de données qui partent on ne sait où.

Et c'est hyper accessible... Suffit de savoir remplir un fichier texte avec quelques indentations (le fameux YAML), et voilà vous savez utiliser ESPHome.

ESPHome fait partie de l'Open Home Foundation ( Source )

Ce qu'il vous faut

• Un ESP32 (genre un Wemos D1 Mini ou un NodeMCU)
• Un capteur DHT22 (température et humidité)
• Quelques fils Dupont
• Temps estimé : 30 minutes

Niveau branchement, c'est pas sorcier. Le DHT22 a 3 broches utiles : VCC sur le 3.3V de l'ESP, GND sur GND, et DATA sur un GPIO de votre choix (le GPIO4 marche nickel). Pensez aussi à ajouter une résistance de 4.7kΩ entre DATA et VCC si vous voulez des lectures béton (beaucoup de modules l'ont déjà intégrée, mais vérifiez bien).

source

Ensuite, pour installer ESPHome sur votre ordi, ça se passe avec pip :

pip install esphome

esphome:
 name: capteur_salon

esp32:
 board: esp32dev

sensor:
 - platform: dht
 pin: GPIO4
 temperature:
 name: "Température Salon"
 humidity:
 name: "Humidité Salon"
 update_interval: 60s

esphome run capteur_salon.yaml