GitHub Carte de Panne

Discussion communautaire

Conseils? Frustrations? Partagez-le ici. Les commentaires utiles comprennent une description du problème, la ville et le code postal.

Méfiez-vous des "numéros d'assistance" ou des comptes de "récupération" qui pourraient être affichés ci-dessous. Assurez-vous de signaler et de voter contre ces commentaires. Évitez de publier vos informations personnelles.

GitHub Rapports de Problèmes

Dernières pannes, problèmes et rapports de problèmes dans les médias sociaux:

• 
  Roland Barbe (@RolandBarbe) a signalé il y a 19 secondes

  Le site @github est hors ligne depuis plusieurs heures. Bien content d’avoir migré tous mes projets sur Forgejo via un petit VPS. Ce service n’est pas fiable.

• 
  Karog (@_karog) a signalé il y a 2 minutes

  @leploutos Perso je dockerise tout mes projets et je donne un accès ssh au LLM, je lui dis de déployer et ça fonctionne à merveille ( je révoque ensuite la clé ssh ). Quand je passe en environnement prod j’ai un github action qui fait les tests + déploie quand je créer une release. Jamais eu de problème avec ça

• 
  Bearman (@xcomdoc) a signalé il y a 2 minutes

  On a trouvé un bug dans l'algo X. C'est pas un bug. C'est 18 000 lignes de code wokiste. Le ranking model préfère le bon message à la bonne réponse. Voilà. Vous pouvez fermer GitHub

• 
  Shen🇨🇭 (@ShenDigital) a signalé il y a 7 minutes

  @leonardoballand La génération vidéo, c’est celle où j’ai le plus galéré, même si je suis assez content du résultat. Les efforts fournis ne justifient pas d’y passer plus de temps pour l’instant. (Projet perso, chargé au démarrage du serveur depuis un GitHub privé.) Si j’ai besoin de vidéos, je passerai plutôt par les plateformes cloud. Quand tu as monté le pod, as-tu injecté ton script d’installation ou utilisé un de leurs templates ?

• 
  Siby_dev 🇸🇳 (@sibyog13) a signalé il y a 12 minutes

  @CheikhAlmudo Oui, sans problème : si ton projet est déjà sur ton PC/GitHub, OpenCode peut reprendre le code existant et continuer exactement là où tu t’étais arrêté avec Antigravity.

• 
  Syaoran (@Syaor4n) a signalé il y a 12 minutes

  Tips Hermes Agent pour ne plus stresser quand t'as un bug en prod mais que t'es pas devant ton pc D'habitude tu t'empresses d'aller voir le mail Sentry et tu penses qu'à ouvrir ton pc pour corriger l'erreur. Mais avec un agent Hermes bien configuré, tu peux juste verouiller ton tél et attendre que l'agent bosse. Ma config en quelques lignes : 1. Mon agent Hermes a accès à ma boite mail : si t'as peur tu peux créer une boite gmail dédiée, le but est de donner un accès aux mails pour que l'agent soit le plus efficace selon les données auxquelles il a accès 2. Quand un mail est reçu sur la boite, l'agent est configuré pour lire le contenu du mail : si c'est un mail Sentry il déclenche un workflow de correction 3. Le mail Sentry contient généralement un identifiant + une description de l'erreur, tout ce qu'il faut pour que l'agent enquête comme il faut. Il a aussi accès au MCP Sentry configuré sur le VPS, pour pouvoir ouvrir le ticket et lire les détails 4. Avec toutes ces informations, l'agent commence à chercher l'origine du problème et comment le corriger 5. Quand il a trouvé comment corriger l'erreur, il envoie une notification sur le serveur Discord, dans un channel spécifique 6. Là c'est à moi de valider, si je lui dis de corriger, il va créer une PR avec la correction qu'il a trouvé et exécuter la suite de tests pour s'assurer que ça ne crée pas de bugs/régressions (+ Github Actions si j'ai encore des crédits...) 7. Quand la PR est publiée je reçois le mail GitHub mais aussi un message Discord : je peux soit vérifier le contenu de la PR (conseillé) et ensuite lui dire de merge soit je lui fais totalement confiance (déconseillé mais... coupable) et je lui dis de merge directement 8. Il merge la PR, ça déclenche tout le workflow de déploiement, l'erreur est corrigée et Sentry détecte la correction Au final, il faut juste laisser l'agent faire dans son coin et vous êtes tranquille, plus besoin de stresser comme un dingue pour aller absolument corriger l'erreur depuis votre ordi !

• 
  Raffaële Azuelos 🕎 🇫🇷 🇮🇱 🇺🇸 🇪🇺 (@RaffAzou) a signalé il y a 19 minutes

  @SamuelDamoy @ValerieHayer @EmmanuelMacron Zéro fait réel! Cité mal traduit et hors contexte de la prise de parole… Autre fait réel L’algo de X, est public sur GitHub depuis janvier, republié toutes les 4 semaines, et depuis le 15 mai tu peux même faire tourner le ranker Phoenix sur ta propre machine, le mini modèle est fourni. Faudrait faire quoi pour être plus transparent ?!?! Publier un guide « pour le nuls » pour être sûrs que TOUS les gauchistes puissent le décortiquer ??

• 
  Kaostyl (@kaostyl) a signalé il y a 21 minutes

  Bon alors petit update sur cette migration de serveur (ou plutot d'environ 150 wordpress vers du static github>cloudflare) par mon agent Hermes.... C'était pas si mal mais pas assez parfait pour que je valide... donc c'est un echec. Hugo etait un mauvais choix, pas top pour des sites multilingue entre autre et surtout j'avais pleins de trucs cassé, un design de *****... Bref !! Je suis en train de tout recommencer avec Astro... et cette fois je borde tout car chaque site à sa particularité donc il faut que le workflow soit capable de gérer l'ensemble des cas particuliers... Je vous tiendrais au courant ! Ce qui est sur c'est que j'ai largement sous estimé la tache mdr et j'ai surement mal fait pleins de trucs...

• 
  Théo Lelong (@ThoTbj) a signalé il y a 21 minutes

  Ce matin, une app IA a généré un rapport de 7 pages via un lien privé. Le parcours marchait. Je l’ai laissée en recette : Lovable avait perdu sa connexion GitHub, avec un risque d’écraser le code. Une démo qui marche n’est pas encore une livraison.

• 
  Affiseo - Romain Brunel (@Affiseo_) a signalé il y a 24 minutes

  La plupart des gens créent de mauvais voice samples pour leurs agents IA. Voici le process exact que j'utilise pour que mes machines produisent du contenu qui sonne vraiment comme moi. Le voice sample classique c'est ça : 'Voici un exemple de post que j'ai écrit. Inspire-toi de ce style.' L'agent produit quelque chose de correct. Générique. Il a vu le texte mais il comprend pas POURQUOI ce texte fonctionne. Quels patterns reviennent. Ce qui sonnerait incongru. Voilà comment je structure les miens. Étape 1 : des vrais posts, pas des exemples inventés. J'utilise uniquement des posts que j'ai réellement publiés et qui ont bien fonctionné. Pas des textes écrits 'pour montrer le style'. Des vrais. Publiés. Avec leur contexte : date, sujet, plateforme. Pour chaque canal minimum 5, idéalement 10+. LinkedIn, X, newsletter, scripts YouTube : fichiers séparés. Étape 2 : annoter ce qui rend chaque post distinctif. Sous chaque exemple, une section 'ce qui marche ici'. Pas des observations génériques. Des observations précises. Exemple réel dans mon fichier voice X : "(et il galère vraiment par rapport à Opus)" est une parenthèse de vécu impossible à inventer. "Y'a pas photo" est du vocabulaire pur, pas du LLM. "0 diversification" au lieu de "Zéro" parce que les chiffres en chiffres sonnent plus brut. Ces annotations apprennent à l'agent exactement où se niche la voix. Pas le ton général. Les détails spécifiques. Étape 3 : documenter les anti-patterns avec des before/after. C'est la partie que presque tout le monde saute. Montrer à l'agent ce qu'il NE doit pas faire est aussi important que montrer ce qu'il doit faire. J'ai dans mon fichier 2 colonnes : 'Ce que l'IA écrit naturellement' et 'Ce que Romain corrige'. Chaque ligne est une correction réelle faite sur un post généré. 'Du coup la panne je la vis comme une pause subie' devient 'C'est pour ça que je build toutes mes machines avec Claude Code. API propres, doc interne, et je file tout ça à mes agents.' Le closer qui résume vs le closer qui ouvre sur quelque chose de nouveau. Vu dans un contexte concret, l'agent intègre la règle bien mieux que si tu l'écris dans l'abstrait. Étape 4 : séparer par canal et par format. Mon voice X n'est pas mon voice LinkedIn. Mon voice newsletter n'est pas mon voice YouTube. Des fichiers séparés, des règles spécifiques par canal. X : flux de pensée, long form autorisé, quasi pas d'emojis, parenthèses de vécu sur les posts longs. LinkedIn : structure plus nette, CTA possible en fin, 800-1500 caractères. Newsletter : ton intime, une idée centrale par email. Un seul fichier voice pour tout ne marche pas. Le canal change trop le format. Étape 5 : le fichier est vivant, pas figé. Un cron tourne chaque semaine. Il récupère mes nouvelles vidéos YouTube, met à jour les voice samples si de nouvelles expressions sont apparues, commit le tout sur GitHub. Mon Second Cerveau grossit en même temps que mon catalogue de contenu. Si je commence à utiliser une expression nouvelle, dans quelques semaines elle est dans le fichier et mes machines l'utilisent naturellement. Le contenu que tu lis là a été produit par des machines qui tournent sur ces 5 étapes. Y'a pas photo sur la différence avec un agent qui a juste eu 'voici mon style, inspire-toi'.

• 
  Quentin Lecocq · CRO SaaS (@QuentinLecocq_) a signalé il y a 27 minutes

  Avant de devenir développeur, j’ai vendu des menuiseries en porte-à-porte. Puis j’ai quitté le commerce, travaillé comme barman et profité des 8-9 mois de chômage qu’il me restait pendant le Covid pour apprendre à coder. Aujourd’hui, je développe sur des parcours utilisés par des millions de personnes et je construis mon activité de consultant CRO. Le chemin n’avait rien de planifié. J’ai fait toutes mes études en marketing en alternance. J’ai commencé par le porte-à-porte, avant de devenir commercial chez le plus gros opérateur télécom français, puis de vendre des services B2B à des professionnels pour un loueur de linge. J’ai appris à prospecter, à présenter une offre, à entendre les objections et à comprendre très vite quand quelqu’un n’était pas convaincu. Mais au bout d’un moment, j’en ai eu marre du commerce. J’ai fini par démissionner. Je n’avais pas encore de plan de reconversion bien construit. Je savais surtout que je ne voulais plus continuer dans cette voie. J’ai donc enchaîné quelques emplois alimentaires, principalement comme barman dans un restaurant italien. À ce moment-là, le développement n’était pas encore mon nouveau métier. C’était simplement une possibilité que je commençais à regarder sérieusement. Puis le Covid est arrivé et le restaurant s’est arrêté. Il me restait 8-9 mois de droits au chômage. J’ai décidé de les utiliser comme une fenêtre pour apprendre le développement web. Pendant cette période, apprendre à coder est devenu mon travail à temps plein. Mon fil conducteur était The Odin Project : de la documentation, des exercices, beaucoup de recherches et surtout des projets à construire réellement. Je publiais tout sur GitHub sous le pseudo Celdama. Le compte existe encore aujourd’hui avec 80 repos : une application météo, un jeu de bataille navale, un panier e-commerce, une application de recettes avec React, Redux et Firebase, un clone d’Instagram… Le code a vieilli, évidemment. Mais je préfère le laisser visible : c’est l’archive brute de mon apprentissage. En parallèle, j’avais créé un compte X sous le nom de Celdama. J’y partageais mes projets, ce que j’apprenais, mes blocages et mes progrès. Ce compte m’a aidé à trouver mon premier poste de développeur. Je l’ai supprimé depuis, mais cette expérience m’a appris quelque chose que j’utilise encore aujourd’hui : montrer ce que tu construis peut ouvrir des portes qu’un CV seul n’ouvre pas. J’ai finalement décroché mon premier poste de développeur dans une ESN à Wasquehal. Pendant trois ans, je suis passé des projets d’apprentissage à de vrais projets en production, notamment pour Saint Maclou, Asmodee et une grande entreprise spécialisée dans la gestion de parcs immobiliers. J’y ai découvert tout ce que les tutoriels montrent rarement : les contraintes métier, les données imparfaites, les bugs, les arbitrages, la maintenance et les conséquences réelles d’une décision technique. Après quatre ans, j’ai décidé de m’arrêter pour prendre du recul et me former davantage. C’est à ce moment-là que je me suis plongé sérieusement dans le CRO, notamment avec la formation La Cargaison. Et beaucoup de pièces ont commencé à se reconnecter. Le marketing m’avait appris à regarder une cible, une offre et un marché. Le commerce m’avait confronté directement aux objections. Le développement m’avait appris à construire, mesurer et corriger. Le CRO réunissait ces trois dimensions autour d’une même question : pourquoi une personne avance, hésite ou abandonne ? Et contrairement à quelqu’un qui s’arrête au diagnostic, je pouvais aussi comprendre les contraintes techniques, écrire des spécifications et participer à l’implémentation. J’ai créé mon auto-entreprise peu avant de rejoindre Boulanger en février 2026. D’un côté, je continue à travailler comme développeur sur des parcours à très grande échelle. De l’autre, je construis une activité de consultant CRO technique pour aider des SaaS et des sites avec moins de trafic à identifier leurs frictions, prioriser les changements et transformer les recommandations en actions réellement implémentables. Je pourrais raconter ce parcours comme plusieurs reconversions. En réalité, je n’avais aucun grand plan pour relier le marketing, le porte-à-porte, les années de développement et le CRO. La cohérence est apparue après. Aujourd’hui, je sais écouter une objection, analyser un parcours, comprendre ce que racontent les données et voir ce qu’il est réellement possible de modifier techniquement. Le CRO a fini par relier des parties de mon parcours que j’avais longtemps considérées comme séparées. Mon organisation Obsidian accompagne une grande partie de cette histoire. Je l’utilise et je l’affine depuis 6-7 ans pour conserver ce que j’apprends, documenter mes projets et relier les idées entre elles. Hermes est arrivé beaucoup plus tard. Il n’a pas créé ce système et il ne réfléchit pas à ma place. Il s’est greffé sur une organisation qui existait déjà. Avant de détailler le bridge Discord, mes consignes, les automatisations et les garde-fous, je trouvais important d’expliquer le parcours derrière les outils. Je commencerai donc la série par mon organisation Obsidian.

• 
  JoYz (@joyzjyc) a signalé il y a 30 minutes

  @kirtandopamine GitHub est très bien en soi ! Le problème ne vient pas de @github ... le problème vient de la gestion de github ... cf. @Microsoft

• 
  Gaetan Semet (@gsemetfr) a signalé il y a 31 minutes

  La conf met surtout en highlight que OpenAI ne sait pas isoler physiquement un rack de serveur pour tester un modèle « debridé », et qu’ils n’ont pas une configuration de base sur artifactory qui interdit toute modification (écriture, mise en cache de github) quand on n’est pas identifié. Il y a tellement de problème de sécurité chez OpenAI que je pense que c’est un coup de communication. Ça devient un coup de pub « notre modèle est tellement fort qu’il s’est échappé ». Ils ont demandé à des enfants de ne pas trouver le moyen de grimper sur la table pour manger les bonbons. On SAIT que les modèles peuvent faire bcp de dégâts, mais si les fournisseurs de ces modèles ne savent pas faire des tests en isolation alors que nous on le fait avec nos petits moyens (on prend un rack avec les serveurs et les GPU et on les isole physiquement de tout réseau pendant l’inference). Le coup d’Artifactory m’a scié. C’est la base, pas d’accès en écriture (la mise en cache depuis GitHub nécessite des droits en modification ) sans authent.

• 
  Occasional ForkBomber (@SkateCLI) a signalé il y a 32 minutes

  @bluetouff Ca m'a fait rire parce que y a juste pas d'instance de runners a mon taff du coup 0 impact. Ca me rends un peu triste parce que il y a pas d'instance de runners mdr, les gens parlent de git hook ia y a juste pas de trucs pour les faire tourner. Pas de panne github, peak perf :'(.

• 
  Roso (@RosoAI) a signalé il y a 33 minutes

  @fontanaen11 @github J’ai jamais eu ce problème