Transcript
00:00:00GitHub est dans une situation très critique, très mauvaise.
00:00:04Il y a de nombreux problèmes, beaucoup liés à l'IA,
00:00:08mais peut-être pas pour les raisons que vous pensez,
00:00:10mais j'y reviendrai plus tard.
00:00:11Et bien sûr, cela a son importance.
00:00:13C'est important car GitHub est l'épine dorsale
00:00:16du développement moderne.
00:00:17Peu importe que vous fassiez de l'open source,
00:00:20que vous mainteniez des projets open source,
00:00:22ou que vous travailliez sur vos propres projets,
00:00:24vos projets personnels ou vos projets annexes,
00:00:26si vous dirigez une petite entreprise, une PME,
00:00:29ou si vous faites partie d'une plus grande société,
00:00:32c'est utilisé comme archive de code pour tout,
00:00:35les flux CI/CD, la collaboration,
00:00:38le travail d'équipe, la gestion des issues,
00:00:42les pull requests et bien d'autres cas d'utilisation.
00:00:47C'est donc crucial, mais comme mentionné,
00:00:49les problèmes sont nombreux.
00:00:51Commençons par examiner ce qui ne va pas
00:00:53avant de voir pourquoi
00:00:54et ce que cela signifie pour l'avenir.
00:00:57Et commençons par un sujet de taille.
00:00:59Une vulnérabilité de sécurité majeure, énorme,
00:01:02voire incroyable, a été signalée hier,
00:01:07au moment où j'enregistre ceci.
00:01:09Une exécution de code à distance sur github.com.
00:01:12C'est tout simplement dément de lire ça.
00:01:16Elle a été découverte par Wiz, une société de sécurité,
00:01:19et elle n'a pas été exploitée.
00:01:21Elle a été découverte, signalée et corrigée.
00:01:25Aucun dommage n'est à déplorer.
00:01:28Selon GitHub,
00:01:31qui a également publié une réponse à ce rapport.
00:01:33Maintenant, je n'entrerai pas dans les détails
00:01:36du fonctionnement de cette vulnérabilité.
00:01:39Je mettrai toutefois le lien de l'article ci-dessous.
00:01:42Mais au final, tout passait par le "git push".
00:01:44Donc pas de phishing,
00:01:46pas de prise de contrôle d'un compte employé,
00:01:49pas d'attaque sur la chaîne d'approvisionnement.
00:01:51On en a vu beaucoup ces dernières semaines,
00:01:54mais non, rien de tout cela ici.
00:01:56Au lieu de cela, c'était juste le "git push",
00:01:58et plus précisément l'option de push standard
00:02:03que l'on peut ajouter à la commande git push
00:02:05pour y joindre des options supplémentaires.
00:02:10Via cette fonctionnalité et la vulnérabilité,
00:02:13ainsi que la façon dont GitHub gérait les pushs,
00:02:17ces chercheurs ont pu joindre du code
00:02:22qui s'exécutait directement sur les serveurs de GitHub.
00:02:27Encore une fois, les détails exacts sont dans le rapport,
00:02:31mais ils ont exploité le fait
00:02:34qu'on pouvait ajouter des métadonnées à un en-tête xstat
00:02:39peuplé à l'aide de ce flag d'options de push.
00:02:44Et ces métadonnées, ces informations transmises
00:02:49avec la requête de push via cet en-tête,
00:02:52n'étaient pas assainies par GitHub.
00:02:54Ils se contentaient d'authentifier la requête,
00:02:58la commande de push.
00:02:59Ils vérifiaient si vous aviez le droit de pusher
00:03:01sur le dépôt visé,
00:03:03mais ils prenaient ensuite ces données d'options
00:03:07pour construire l'en-tête sans les nettoyer.
00:03:12Cela a permis aux chercheurs en sécurité
00:03:15d'exécuter une commande qui n'était pas restreinte
00:03:18au dépôt sur lequel ils pushaient,
00:03:21mais qui tournait librement sur les serveurs de GitHub
00:03:24et pouvait accéder à d'autres dépôts,
00:03:27y compris des dépôts privés.
00:03:29Cette faille a été signalée et corrigée,
00:03:33elle n'existe plus aujourd'hui,
00:03:35mais c'est évidemment une faille majeure.
00:03:39C'est très grave d'avoir une vulnérabilité
00:03:43permettant l'exécution de code à distance sur github.com.
00:03:45C'est vraiment énorme.
00:03:47C'est donc un gros problème,
00:03:48mais ce n'est bien sûr pas le seul.
00:03:51Le 23 avril, soit quelques jours plus tôt,
00:03:56il y a eu un incident majeur lié aux merge queues.
00:04:01Les merge queues de GitHub, au cas où,
00:04:04sont une fonction destinée aux dépôts
00:04:07ayant une forte activité, beaucoup de travail en cours
00:04:11et de nombreuses pull requests entrantes.
00:04:13Pour s'assurer de ne pas devoir merger
00:04:16chaque PR avant d'en envoyer une nouvelle,
00:04:19car on veut faire une pull request
00:04:21par rapport au dernier état du dépôt,
00:04:24de la branche principale par exemple,
00:04:26et pour éviter de devoir merger
00:04:28chaque PR avant d'en ouvrir une autre.
00:04:30Finalement, cette fonction de file d'attente existe,
00:04:34avec pour simple but de créer efficacement
00:04:38un genre de merge intermédiaire
00:04:42en créant un nouvel état du dépôt ou de la branche
00:04:46visée pour chaque pull request.
00:04:49Si une nouvelle pull request est ajoutée
00:04:51à la chaîne des pull requests,
00:04:53elle est aussi déjà mergée et combinée aux PR
00:04:57qui la précèdent dans la branche principale
00:04:58pour que les nouvelles PR soient ouvertes
00:05:01comme si les précédentes avaient déjà été mergées.
00:05:05Cela permet simplement aux équipes de travailler plus vite
00:05:08car on peut ouvrir de plus en plus de pull requests
00:05:10sans attendre que celles de devant soient finies.
00:05:13À un moment donné, elles seront mergées,
00:05:15mais cela permet de continuer à travailler,
00:05:17ce qui est crucial pour les grandes équipes.
00:05:19Ce qui est aussi important avec cette fonction,
00:05:22c'est bien sûr qu'elle fonctionne correctement.
00:05:24Et ce qui s'est passé le 23 avril,
00:05:28c'est qu'il y a eu une erreur, un bug de logique interne
00:05:32dans la manière dont GitHub résolvait ces PR
00:05:37de sorte qu'au final, cela créait un merge
00:05:41qui omettait certaines informations, menant
00:05:45à un commit invalide et supprimant des parties
00:05:49de l'historique Git à cet endroit.
00:05:50Les données n'ont pas été réellement perdues,
00:05:53mais la fonctionnalité a mal fonctionné
00:05:55et a produit ce commit incorrect.
00:05:57C'est la version courte, l'essentiel de l'histoire.
00:06:00Et bien sûr, c'est aussi totalement inacceptable
00:06:03si vous êtes une grande entreprise ou n'importe quelle société
00:06:06comptant sur cette fonction et que votre projet finit
00:06:09dans un état corrompu sans explication claire.
00:06:13C'est inacceptable, évidemment.
00:06:16Et votre première pensée n'est probablement pas
00:06:19qu'il y a un bug interne dans la merge queue.
00:06:23C'est plutôt que vous avez fait une erreur.
00:06:26On passe donc beaucoup de temps à chercher l'erreur
00:06:28avant de découvrir que non, c'est GitHub.
00:06:30Et tout cela vient s'ajouter
00:06:33aux problèmes récurrents de disponibilité de GitHub.
00:06:38La page de statut officielle n'est pas brillante,
00:06:42disons qu'elle est correcte, mais on n'a pas les "trois neuf"
00:06:46de disponibilité ici, du moins pour la plupart des systèmes.
00:06:49Ils rapportent l'uptime séparément par système.
00:06:53Mais les choses sont un peu différentes si on regarde
00:06:55la page "missing GitHub status",
00:06:57qui suit la disponibilité d'une autre manière
00:07:00et compte chaque petit incident comme un problème,
00:07:04comme une interruption de service au final.
00:07:05Ici, on a un uptime horrible pour un système aussi crucial
00:07:10que GitHub, c'est totalement inacceptable.
00:07:14Nous avons eu des problèmes d'uptime ces derniers mois
00:07:18et même déjà l'année dernière.
00:07:20Il y a aussi eu de petits bugs ici et là,
00:07:23simplement pas aussi gros que celui-ci ou aussi graves
00:07:26que cette vulnérabilité de sécurité.
00:07:28Mais oui, il y a beaucoup de problèmes
00:07:31et GitHub est devenu une plateforme peu fiable
00:07:36à ce stade, malheureusement,
00:07:38ce qui est un désastre vu son rôle et son importance
00:07:43dans, comme je le disais, le développement moderne,
00:07:47quel que soit le type de travail que vous faites.
00:07:50Un autre problème est que la communication de GitHub
00:07:54a été, disons, plutôt limitée.
00:07:59Il n'y a pas eu beaucoup de communication,
00:08:01mais un article de blog a été partagé le 28 avril,
00:08:06avant cette vulnérabilité de sécurité,
00:08:10où ils expliquent un peu ce qui se passe,
00:08:14d'où viennent les problèmes,
00:08:16qu'ils comprennent que leur stratégie de communication
00:08:19n'était pas idéale et que les choses vont s'améliorer.
00:08:23C'est maintenant la partie suivante.
00:08:25D'où viennent ces problèmes ?
00:08:28La déclaration officielle cite l'IA comme raison,
00:08:32mais pas dans le sens où les ingénieurs de GitHub
00:08:36chez Microsoft utiliseraient l'IA pour livrer des logiciels
00:08:40ou des mises à jour buggées à GitHub.
00:08:43C'est possible, mais nous n'en avons pas la preuve.
00:08:47La raison principale invoquée ici est plutôt
00:08:51qu'à cause de l'IA, il y a beaucoup plus de projets
00:08:57créés, beaucoup plus de code généré,
00:09:00et qu'au final, tous ces projets et tout ce code
00:09:03sont pushés sur GitHub.
00:09:04Ils partagent des graphiques, bon, pas très utiles,
00:09:09mais ils partagent quelques graphiques.
00:09:12Ils ne sont pas très utiles car il n'y a pas d'axe Y.
00:09:14On ne voit pas les chiffres absolus,
00:09:17mais on peut bien sûr voir les relations ici.
00:09:20On voit clairement qu'au cours de l'année 2025,
00:09:23il y a eu une hausse brutale des pull requests mergées,
00:09:28des commits pushés et des nouveaux dépôts ouverts.
00:09:32Ce sont tous nos projets annexes qu'on crée
00:09:34sans jamais les finir avec l'IA.
00:09:36Et en 2026, évidemment, pour tous ces indicateurs,
00:09:41la courbe s'envole littéralement vers le ciel.
00:09:46C'est donc une tendance assez claire.
00:09:49Et ce trafic, ce genre d'augmentation de trafic,
00:09:54mettrait n'importe quel système sous pression.
00:09:58C'est particulièrement problématique pour GitHub
00:10:01car ils sont en train de migrer
00:10:05d'une structure monolithique et de leurs propres
00:10:09centres de données vers le cloud Azure
00:10:13et vers un système plus fragmenté, en microservices,
00:10:17au lieu de cette structure monolithique.
00:10:21C'était déjà un processus en cours avant 2026.
00:10:26Mais cela signifie que maintenant ce processus de migration
00:10:31est frappé par ce pic de demande,
00:10:34ce qui signifie que même en pleine migration,
00:10:36vous devez en quelque sorte stabiliser le système actuel
00:10:39tout en poursuivant la migration,
00:10:40ce qui, espérons-le, aidera à gérer cette augmentation
00:10:44du trafic à l'avenir.
00:10:46C'est l'espoir, bien sûr, il n'y a aucune garantie.
00:10:50Mais c'est évidemment un défi que GitHub doit relever.
00:10:52Ils indiquent ici avoir commencé à exécuter un plan
00:10:56pour décupler la capacité de GitHub en octobre 2025.
00:11:01On peut donc dire qu'à ce moment-là, ils ont vu
00:11:04que tout cela augmentait.
00:11:06Enfin, ils pouvaient déjà le voir avant,
00:11:09mais c'est là qu'ils ont décidé de décupler leur capacité.
00:11:13Puis en février 2026, ils ont réalisé :
00:11:16« D'accord, il nous faut 30x, pas 10x », car, eh bien,
00:11:20à cause de cette évolution ici, n'est-ce pas ?
00:11:22Cela doit bien sûr s'ajouter à la migration.
00:11:28Et c'est une tâche colossale, de toute évidence.
00:11:33Certes, cela fait partie de Microsoft, ce n'est pas une petite startup,
00:11:37mais c'est néanmoins une tâche intimidante.
00:11:39Et c'est un aspect de tout ce problème GitHub
00:11:44pour lequel j'ai une certaine sympathie, car je pense qu'il est facile
00:11:47de détester GitHub, de s'en moquer.
00:11:51Et on peut tout à fait le faire.
00:11:52Je reviendrai sur d'autres problèmes qui sont vraiment graves.
00:11:56Mais une telle augmentation du trafic serait un énorme problème
00:11:59pour n'importe quel système, pour n'importe quelle entreprise.
00:12:03Et il est difficile de croire qu'un concurrent de GitHub
00:12:07s'en sortirait mieux dans cette situation.
00:12:09Pourtant, bien sûr, ce n'est pas une excuse.
00:12:10Cela fait partie de Microsoft.
00:12:12Et par conséquent, ils ont sans aucun doute les ressources
00:12:16pour mener à bien cette transition et adapter leurs systèmes
00:12:20à ce nouveau monde et à ce nouveau volume de trafic.
00:12:24Mais il y a un autre problème important ici avec GitHub.
00:12:28C'est qu'il n'y a plus de PDG.
00:12:32Le précédent PDG, Thomas Domke,
00:12:37a pris sa retraite ou a démissionné, ou a annoncé son départ
00:12:41en août 2025.
00:12:43Et Microsoft n'a pas nommé de nouveau PDG.
00:12:48Au lieu de cela, GitHub a été intégré à Core AI,
00:12:51une division interne de Microsoft qui, comme son nom l'indique,
00:12:56se consacre entièrement à l'IA et à la création d'outils et de plateformes d'IA.
00:13:01Et GitHub en fait partie.
00:13:03Il est donc clair que la mission de GitHub, du point de vue de Microsoft,
00:13:07est de devenir une pièce de cette chaîne d'outils d'IA,
00:13:11de cette révolution de l'IA.
00:13:13Et manifestement, Microsoft impose Co-Pilot
00:13:15dans tous ses produits.
00:13:16D'ailleurs, lors de GitHub Universe 2023,
00:13:20ils disaient déjà qu'ils allaient transformer GitHub
00:13:24en une plateforme de développement propulsée par l'IA,
00:13:28avec GitHub partout.
00:13:30Cela inclut de nouvelles fonctionnalités
00:13:32qui aident à créer des tickets avec GitHub Co-Pilot,
00:13:36ce qui est un énorme problème pour les mainteneurs open source,
00:13:39mais aussi simplement la présence pure de GitHub Co-Pilot
00:13:43partout sur GitHub.
00:13:44Il y a ce truc « Agent HQ » ici sur GitHub,
00:13:48[github.com/copilot](https://github.com/copilot),
00:13:49où vous pouvez interagir avec GitHub Co-Pilot
00:13:52et travailler sur votre code directement depuis GitHub Co-Pilot
00:13:55sans jamais ouvrir d'IDE local ou d'outil d'agent de codage,
00:14:00et bien d'autres choses encore.
00:14:02GitHub Co-Pilot est partout dans GitHub,
00:14:05tout comme Co-Pilot est partout
00:14:07dans tous les produits Microsoft, j'imagine.
00:14:10Et c'est bien sûr une décision stratégique claire
00:14:14qui va un peu à l'encontre de la mission réelle de GitHub,
00:14:19du moins la mission que GitHub avait par le passé.
00:14:23Car, comme je l'ai mentionné au tout début,
00:14:25GitHub est important pour différents types de développeurs
00:14:29pour toutes sortes de cas d'utilisation.
00:14:31Les mainteneurs open source l'utilisent pour y héberger leur code source
00:14:36et collaborer avec d'autres mainteneurs
00:14:39et d'autres contributeurs de la communauté.
00:14:41Les tickets (issues) sont essentiels pour détecter, eh bien, les problèmes
00:14:45et travailler dessus.
00:14:46Les « pull requests » sont importantes pour permettre à d'autres
00:14:50de contribuer à la base de code.
00:14:52Les discussions peuvent être formidables pour débattre de nouvelles fonctionnalités
00:14:55ou des orientations d'un dépôt ou d'une bibliothèque, etc.
00:15:01Il y a de nombreuses fonctionnalités liées à cela
00:15:03qui aident les mainteneurs open source,
00:15:04ou du moins qui les aidaient par le passé.
00:15:07D'autres utilisent GitHub simplement comme une ressource
00:15:11pour héberger des liens ou des documents,
00:15:13comme tous ces dépôts « awesome Go », « awesome Rust »,
00:15:17etc., que vous pouvez utiliser pour trouver facilement des ressources
00:15:20si vous voulez travailler avec Go ou Rust.
00:15:22J'utilise aussi GitHub pour héberger les ressources de mes cours,
00:15:26comme ici pour mon cours Codex par exemple,
00:15:29et pour beaucoup d'autres cours également.
00:15:31On peut donc même détourner l'usage de GitHub
00:15:33pour s'en servir comme d'un simple stockage de documents.
00:15:36Et puis, bien sûr, on peut aussi l'utiliser pour le travail CI/CD.
00:15:40En entreprise, vous utilisez peut-être GitHub
00:15:43pour y héberger votre code source,
00:15:46pour que les membres de votre équipe y collaborent
00:15:50avec des pull requests, etc.
00:15:52Et puis, très souvent, GitHub
00:15:54fait aussi partie du pipeline CI/CD
00:15:57où un nouveau push sur la branche principale, par exemple,
00:15:59déclenche un pipeline CI/CD.
00:16:02Cela peut se faire à l'aide de GitHub Actions,
00:16:05bien que ce produit ait ses propres problèmes.
00:16:08Mais cela peut aussi servir à déclencher un pipeline CI/CD
00:16:12sur n'importe quel autre fournisseur, pas seulement GitHub Actions.
00:16:16GitHub joue donc évidemment un rôle très important
00:16:20pour le travail de développement classique et traditionnel.
00:16:24Mais Microsoft a décidé que non,
00:16:27cela devait devenir une plateforme de développement propulsée par l'IA,
00:16:31et pas seulement une plateforme de développement.
00:16:33Et il y a là une sorte d'inadéquation.
00:16:37Les développeurs ne veulent pas forcément Co-Pilot
00:16:41dans chaque aspect de GitHub.
00:16:43J'imagine que les utilisateurs de produits Microsoft en général
00:16:46ne veulent pas GitHub dans tous leurs produits,
00:16:48mais c'est une autre histoire.
00:16:49Et GitHub a négligé les fonctionnalités de base
00:16:53qui sont importantes pour les développeurs.
00:16:56Prenons par exemple le développement open source.
00:17:00Les mainteneurs de projets open source sont submergés
00:17:03de tickets et de pull requests générés par l'IA.
00:17:07Le problème ici est bien sûr l'asymétrie.
00:17:10Il est facile d'utiliser l'IA pour générer du code ou des tickets.
00:17:14Il est bien plus difficile de réviser tout cela.
00:17:19De réviser ce code et ces tickets générés.
00:17:24C'est quelque chose que tout développeur sait,
00:17:26pour peu qu'il ait déjà travaillé avec l'IA.
00:17:27Vous pouvez facilement lancer trois agents IA ou plus
00:17:30et les faire travailler sur vos projets,
00:17:32totalement en dehors de GitHub.
00:17:33Vous pouvez le faire sur votre machine avec CodeX,
00:17:35Claude Code, et ainsi de suite.
00:17:36Mais si vous ne choisissez pas la voie du codage à l'aveugle,
00:17:39ce que vous ne devriez pas faire selon moi,
00:17:41vous devez réviser ce code à un moment donné.
00:17:44Et cela prend du temps.
00:17:45Et ce n'est pas très amusant, du moins pour moi.
00:17:48Maintenant, si vous lancez trois agents,
00:17:51vous devez réviser le résultat de trois agents.
00:17:54Vous pouvez réduire le nombre d'agents si c'est trop
00:17:57pour vous et que vous trouvez que vous n'êtes pas
00:17:59vraiment productif de cette façon.
00:18:00Mais quand vous êtes mainteneur open source sur GitHub,
00:18:03vous vous noyez sous les tickets et pull requests générés par l'IA
00:18:07et vous n'avez jamais que deux options principales.
00:18:09Vous pouvez les ignorer, ce qui vide un peu leur but de sa substance,
00:18:13mais c'est une stratégie valable, évidemment.
00:18:16Ou vous essayez de les traiter,
00:18:18et vous finissez en burn-out parce que c'est tout simplement trop,
00:18:21car contrairement à votre propre travail de développement personnel,
00:18:25vous ne pouvez pas simplement réduire le flux de tickets
00:18:29et de pull requests entrants.
00:18:30Vous pouvez utiliser moins d'agents de votre côté
00:18:33si vous trouvez que vous n'êtes pas efficace ou productif
00:18:36avec tous les agents que vous tentez de faire tourner.
00:18:38Mais vous ne pouvez pas faire ça avec les dépôts publics.
00:18:41Vous ne contrôlez pas combien de personnes vont poster
00:18:45des tickets générés par l'IA ou partager des pull requests avec vous.
00:18:49C'est donc un problème majeur pour les mainteneurs open source
00:18:53et c'est pourquoi toute la scène open source
00:18:56et la philosophie derrière l'open source
00:18:59traversent de graves difficultés actuellement à cause de l'IA.
00:19:04Et GitHub n'aide pas du tout.
00:19:06Au contraire, ils font l'inverse.
00:19:08Ils facilitent activement le partage
00:19:13de « tickets-poubelle » générés par l'IA, etc.
00:19:15Ce dont les mainteneurs et les développeurs auraient besoin,
00:19:18ce serait des outils plus efficaces pour gérer
00:19:22tous ces tickets et pull requests générés par l'IA.
00:19:25Mais GitHub ne travaille pas là-dessus.
00:19:27Ça ne fait pas partie de leur stratégie, je suppose.
00:19:29Alors, peut-être que cela changera.
00:19:30Le message officiel de GitHub que j'ai mentionné plus tôt
00:19:35parle principalement des problèmes de fiabilité et de disponibilité,
00:19:39et de leur volonté d'être plus transparents, etc.
00:19:41Mais ils mentionnent aussi avoir pris l'engagement
00:19:44de soutenir les développeurs.
00:19:46Nous verrons, je ne suis pas très optimiste
00:19:49car finalement, cela fait partie de Microsoft
00:19:52et ils ont leur propre stratégie ici.
00:19:55Mais qu'est-ce que cela signifie pour GitHub, alors ?
00:19:59Est-il temps de migrer ailleurs ?
00:20:02J'ai entendu quelques voix ici et là sur X
00:20:05dire qu'il est temps de trouver une alternative à GitHub.
00:20:08Je sais que certains projets ont déjà migré.
00:20:12SIG est peut-être le plus emblématique.
00:20:15Ils ont migré de GitHub vers Codeberg en novembre 2025.
00:20:20Mais soyons réalistes.
00:20:22D'une part, comme je l'ai dit plus tôt,
00:20:24le volume de trafic qui frappe GitHub
00:20:28submergerait n'importe quel concurrent également.
00:20:31Probablement même plus que GitHub,
00:20:32car ils ne font pas partie de Microsoft.
00:20:35On ne verra donc certainement pas GitHub se faire remplacer.
00:20:40Et bien que certains projets individuels,
00:20:42particulièrement des projets open source, puissent quitter GitHub
00:20:45pour des raisons que je comprends parfaitement,
00:20:48toutes ces entreprises, tous ces développeurs individuels
00:20:52ne migreront probablement pas.
00:20:54GitHub possède, malgré tous ses problèmes,
00:20:57une plateforme riche en fonctionnalités qui sont intégrées
00:21:02aux flux de travail et au quotidien de nombreux développeurs.
00:21:06Surtout pour les entreprises, bien sûr,
00:21:08il n'est pas facile pour elles de remplacer GitHub
00:21:11par un autre fournisseur.
00:21:13Même si tous les problèmes de fiabilité
00:21:15sont évidemment des problèmes majeurs pour les entreprises également,
00:21:18elles seront capables et prêtes à endurer beaucoup plus de douleur
00:21:23avant même d'envisager de partir.
00:21:25J'en suis certain.
00:21:26GitHub est tout simplement une plateforme trop importante.
00:21:30C'est la plateforme pour mettre votre code géré par Git
00:21:35dans le cloud, y travailler et y collaborer.
00:21:39Je suis donc sûr qu'elle ne disparaîtra pas,
00:21:43même si la situation venait à s'aggraver.
00:21:45Bien sûr, les gens finiraient par partir
00:21:47si GitHub ne faisait rien,
00:21:49mais il est clair qu'ils agissent,
00:21:50au moins concernant les problèmes de disponibilité et de fiabilité.
00:21:55Quant au travail open source et aux problèmes rencontrés là-bas,
00:21:58notamment les tickets-poubelle d'IA, nous verrons.
00:22:01Même là, je pense que GitHub est tout simplement trop important
00:22:07et offre trop d'avantages aux mainteneurs open source
00:22:10pour qu'ils partent tous.
00:22:14Mais je comprends tout à fait que des projets individuels
00:22:17quittent GitHub, cela pourrait arriver.
00:22:20Mais oui, pour les entreprises et pour GitHub en général,
00:22:23ça restera en place.
00:22:24Néanmoins, on ne peut qu'espérer que cette situation
00:22:28sera peut-être, peut-être, un signal d'alarme pour Microsoft.
00:22:33Peut-être qu'ils remettront un PDG à la tête de GitHub.
00:22:38Peut-être comprendront-ils son importance.
00:22:41Peut-être comprendront-ils qu'il s'agit d'une plateforme
00:22:45pour les développeurs et le développement, et non d'une plateforme d'IA avant tout.
00:22:49Mais bon, on peut espérer.
00:22:52Je ne sais pas si et quand cela arrivera.
00:22:55Mais voilà, c'est la situation actuelle de GitHub.
00:23:00C'est mauvais, vraiment mauvais.
00:23:03Et cela restera difficile dans un avenir proche,
00:23:06mais au moins, la fiabilité s'améliorera, je l'espère,
00:23:11plus tard cette année.
00:23:13On verra bien, j'imagine.