Discussion :

[Patrick Ruiz]

GitHub doit lutter pour sa survie au sein de Microsoft. Le service web d’hébergement et de gestion de développement de logiciels fait face à des défis opérationnels, stratégiques et concurrentiels.

Lorsque Microsoft a finalisé en 2018 le rachat de GitHub pour un montant de 7,5 milliards de dollars, les développeurs ont réagi avec inquiétude. Certains craignaient que Microsoft ne prenne le contrôle de GitHub, tandis que d'autres préféraient attendre de voir comment les choses allaient évoluer. Près de huit ans plus tard, GitHub lutte aujourd'hui pour sa survie, confronté à une multiplication des pannes, à des problèmes de sécurité et à la pression exercée par ses concurrents.

Rien qu’au cours des dernières semaines, GitHub a connu plusieurs pannes majeures, la divulgation d’une faille permettant l’exécution de code à distance, ainsi que le piratage de ses dépôts de code internes à cause d’une extension VS Code « corrompue » installée sur l’appareil d’un employé. Des employés actuels et anciens de GitHub dressent tous le portrait d’une entreprise aux prises avec un manque de leadership et la pression exercée par ses concurrents.

Bon nombre de difficultés de GitHub trouvent leur origine avec le départ de l’ancien PDG – Thomas Dohmke

Bon nombre des difficultés actuelles de GitHub trouvent leur origine l'été dernier. L'ancien PDG de GitHub, Thomas Dohmke, a démissionné, provoquant un bouleversement majeur dans le fonctionnement de GitHub sous le contrôle de Microsoft. Microsoft n'ayant pas pourvu le poste de PDG laissé vacant par Dohmke, le reste de l'équipe de direction de GitHub a dû se mettre directement sous la tutelle de l'équipe CoreAI de Microsoft. Les employés de GitHub ont eu du mal à s'adapter après avoir été fiers de leur indépendance pendant si longtemps.

L'équipe CoreAI au sein de laquelle opère GitHub est dirigée par Jay Parikh, ancien directeur de l'ingénierie chez Meta, que Satya Nadella, PDG de Microsoft, a personnellement recruté l'année dernière pour contribuer à la transformation de l'entreprise dans le domaine de l'IA.

Depuis le départ de Dohmke, GitHub connaît une fuite des talents. Certains employés de GitHub ont suivi Dohmke chez Entire, sa nouvelle start-up, une plateforme destinée aux développeurs qui semble appelée à concurrencer directement GitHub. Sur les 30 employés répertoriés chez Entire, au moins 11 travaillaient auparavant chez GitHub.

Outre des nouveaux venus dans la filière comme Entire, GitHub doit faire face à la menace concurrentielle que représentent Cursor et Claude Code. Alors que GitHub Copilot avait pris une longueur d’avance dans la course à l’IA appliquée au codage, il a pris du retard sur ses rivaux au cours de la dernière année. The Information rapporte en début de semaine que Jay Parikh avait averti en privé ses collègues que GitHub « faisait face à une menace critique ». Microsoft aurait en sus envisagé d'acquérir Cursor ces derniers mois afin de combler l'écart avec GitHub Copilot. Des rapports indiquent que Microsoft en est au rendu au point d’annuler ses propres licences Claude Code dans le but d'inciter ses développeurs à contribuer à l'amélioration de GitHub Copilot.

Microsoft aura donc besoin des meilleurs talents pour faire face à la concurrence

Les remaniements à la direction et les départs n’ont pas cessé ces derniers mois. Julia Liuson, cadre chevronnée de Microsoft, a annoncé le mois dernier son départ de l’entreprise après 34 ans de service. GitHub relevait auparavant de sa responsabilité avant la création de CoreAI l’année dernière, et elle était chargée de superviser les revenus, l’ingénierie et le support de GitHub après le départ de Dohmke.

Jared Palmer, qui venait tout juste de rejoindre GitHub en octobre en tant que vice-président senior, quitte déjà l'entreprise pour occuper un poste chez Xbox en tant que vice-président de l'ingénierie et conseiller technique de la PDG de Xbox, Asha Sharma. La nouvelle dirigeante de Xbox a recruté plusieurs anciens cadres de Microsoft CoreAI, qui semblent plus que désireux de se soustraire à l'autorité de Parikh.

Elizabeth Pemmerl, ancienne directrice des recettes de GitHub, a également annoncé sa démission le mois dernier. Dan Stein, ancien responsable des logiciels et des plateformes numériques chez Microsoft Customer and Partner Solutions (MCAPS), a été nommé nouveau directeur des recettes de GitHub. Les recettes de GitHub relevant désormais de MCAPS et le développement des produits étant réparti au sein de la division Développeurs de Microsoft, certains au sein de GitHub ont le sentiment qu’il n’y a plus d’équipe de direction.

Les pannes se sont multipliées sur la plateforme entraînant la colère des utilisateurs et leur départ vers d’autres services

Les pannes ont été particulièrement fréquentes au cours de l'année écoulée, à tel point que Vladimir Fedorov, directeur technique de GitHub, a dû présenter personnellement ses excuses pour les derniers incidents survenus le mois dernier. Fedorov a reconnu que GitHub avait du mal à faire face à l'énorme pic de croissance enregistré ces dernières années, dû à l'augmentation du nombre de pull requests, de commits et de nouveaux dépôts.

Ces pannes surviennent alors que GitHub est en pleine migration vers les serveurs Azure, un projet que M. Fedorov a lancé quelques mois après avoir rejoint GitHub afin de tenter de résoudre les problèmes de capacité des centres de données. J'avais prévenu à l'époque que cette migration risquait d'entraîner des pannes en cours de route, en raison de la complexité des clusters MySQL gérés par GitHub.

GitHub fait aussi face à une vague de critiques suite à sa décision de passer à une facturation à l'utilisation pour son outil de codage basé sur l'IA

À partir du mois de juin, chaque forfait Copilot inclura un quota mensuel de crédits IA GitHub, les abonnés ayant la possibilité d'acheter des crédits supplémentaires. Actuellement, les développeurs peuvent tester l'outil sans se soucier des coûts, car GitHub les fait simplement basculer vers un modèle d'IA moins performant une fois les limites atteintes. Avec le nouveau système, les utilisateurs de GitHub Copilot seront coupés du service s'ils ne paient pas pour obtenir davantage de crédits.

Conclusion

GitHub est actuellement confronté à un ensemble complexe de défis opérationnels, stratégiques et concurrentiels. L'utilisation croissante d'agents de codage basés sur l'IA génère une charge et un trafic sans précédent sur la plateforme, sans pour autant se traduire par une augmentation correspondante des revenus, en partie à cause des services gratuits existants et de modèles tarifaires obsolètes. Conjugués à une migration vers le cloud qui perturbe le fonctionnement et à un vide au niveau de la direction, ces facteurs ont entraîné des pannes très médiatisées et un mécontentement des clients. Microsoft réagit par des réformes techniques et des hausses de prix visant à stabiliser et à monétiser la plateforme. En parallèle, la concurrence croissante dans le domaine du codage assisté par l'IA accentue la pression pour innover et fidéliser les clients, en particulier les grandes entreprises découragées par le coût élevé de la migration vers des plateformes concurrentes. La capacité de GitHub à conserver sa position dominante dépend de sa capacité à résoudre les problèmes de stabilité de l'infrastructure, à adapter sa tarification et à renforcer les fonctionnalités de la plateforme dans un contexte de concurrence accrue sur le marché.

Et vous ?

Ces rapports en lien avec la qualité du service chez GitHub sont-ils cohérents avec la réalité dont vous êtes au fait ? Partagez vos anecdotes
La situation aurait-elle pu être différente chez GitHub ? A quelles conditions ?
Sur quelles alternatives à GitHub votre entreprise s’appuie-t-elle pour ses projets logiciels ?

Voir aussi :

L'âge d'or du forfait IA illimité tire à sa fin : pubs ciblées, limitations d'usage, fonctionnalités verrouillées, prix en hausse. L'IA agentique contraint les fournisseurs à changer leurs modèles économiques

Anthropic bloque l'utilisation par des clients tiers des abonnements à Claude Code : la fin de l'interopérabilité et de l'ouverture des outils de dev ou simple épisode dans la bataille des assistants IA ?

Après qu'Anthropic ait bloqué brutalement Openclaw techniquement et légalement, Sam Altman l'opportuniste en profite pour récupérer le bébé dans le giron d'OpenAI

[Anselme45]

Est-ce que microsoft considère aujourd'hui que son IA y a "pompé" toutes les données qui lui étaient utiles et que les coûts engendrés par github ne sont plus nécessaires?

[air-dex]

Hâte du séisme que provoqueront la fermeture de GitHub, et surtout par voie de conséquence celle aussi de NPM dont GitHub est propriétaire.

[Eric80]

alors que les soucis autour de GitHub font rage, la grosse boite pour laquelle je bosse, qui utilise Gitlab community en interne et auto hébergé depuis des années, avec 300k repo, et tout dans le cloud AWS, a pris la décision stratégique incompréhensible pour 80% des développeurs de passer à GitHub Entreprise au lieu de Gitlab... Ou comment jeter de l'argent par les fenêtres, du temps et de la frustration des équipes.

[Patrick Ruiz]

GitHub cite un dysfonctionnement de l’autoscaling et une tempête de tentatives de reconnexion dans VS Code comme responsables de sa récente panne de 8 h
Qui s’explique par sa structure de SaaS centralisé

Le 17 août 2026, GitHub a subi une [nouvelle] panne mondiale pendant près de 8 heures. L’incident a débuté à approximativement 15 h 40 en France métropolitaine avant d’être déclaré résolu à 23 h 15. Ce n’était pas une simple indisponibilité de l’interface web. La panne à touché les API, les Pull Requests, les webhooks, l'outil [GitHub Actions] et l'authentification. En tant que plateforme SaaS centralisée et interconnectée, ses caractéristiques structurelles et opérationnelles ont amplifié l'impact de la situation.

The RCA for the outage we had at GitHub yesterday is live.

We're sorry it happened and hope this answers your questions about it. The team is already working on the actions listed here to fix it.https://t.co/1BZfMYncoU

— Cassidy (@cassidoo) August 18, 2026

La panne GitHub du 17 août 2026 illustre les inconvénients pour les équipes de développement informatique de s’appuyer uniquement sur un SaaS centralisé.

Bien que Git soit décentralisé, GitHub impose un serveur maître officiel. Ainsi, les validations de code et autres historiques d’équipe convergent vers un même centre. C’est cette architecture qui explique en grosse partie la dernière panne.

En effet, lorsqu’un développeur dispose déjà du dépôt d’un projet informatique sur sa machine, il peut continuer à consulter l’historique, créer une branche et produire des commits sans joindre GitHub. C’est là qu’apparaît l’aspect décentralisé (via Git). Pour le reste, il faut s’appuyer sur l’architecture SaaS centralisée.

Une équipe ne livre pas un produit avec des commits locaux seulement. Son fonctionnement dépend aussi d’autres services dépendant de l’architecture SaaS de GitHub :

• la synchronisation avec le dépôt distant ;
• la revue et la fusion des changements ;
• l’exécution des tests automatisés ;
• la production et le stockage des artéfacts ;
• les webhooks vers d’autres services ;
• l’authentification des collaborateurs ;
• le déclenchement des déploiements.

Au plus fort de l'incident, GitHub a signalé un taux d'erreur d'environ 20 % pour le trafic Web et API, et un taux d'erreur stupéfiant de 50 % pour les téléchargements bruts de dépôts et d'archives. Parmi les services touchés, on trouve justement ceux qui apparaissent dans la liste ci-dessus. En gros, la panne du 17 août illustre la différence entre « posséder une copie du code » et « maitriser la chaîne qui permet de le livrer. »

Time to invest in self hosted runners.

— Snazzie (@ItsSnazzie) August 18, 2026

Tout est parti d’une forte hausse du trafic externe qui a mené à une surcharge des couches d’authentification, isolant ainsi de nombreuses entreprises.

La dépendance à l’authentification centralisée est l’un des nœuds de la dernière panne sur GitHub. Les pannes sur les couches SAML, OIDC et SCIM ont bloqué l'accès des équipes d'entreprise, rendant les services inaccessibles même lorsque le code de base restait potentiellement joignable.

En effet, les systèmes SaaS modernes gèrent des appels automatisés fréquents. Face aux premiers ralentissements, les clients VS Code, les scripts CI/CD et les agents ont multiplié les nouvelles tentatives automatiques et ont saturé les serveurs.

La croissance exponentielle des requêtes générées par les assistants d’intelligence artificielle et les flux de travail automatisés pèse lourdement sur l'infrastructure de la plateforme, rendant la gestion de la concurrence plus fragile lors d'incidents de mise à l'échelle.

En gros, la panne du 17 août 2026 illustre les inconvénients de la centralisation de la chaîne de valeur DevOps. En effet, GitHub opère selon une espèce de modèle « Tout-en-un ». La plateforme ne sert pas juste à héberger du code, mais orchestre toute la chaîne de livraison logicielle et c’est en cela que se situe le piège pour les équipes de développement informatique. Quand les couches web et les API ralentissent, c’est tout l’écosystème de développement qui se fige.

We had a big outage on GitHub Monday, and the root cause is here for transparency's sake. I know this has been posted all over by other Hubbers, but I want to make sure my audience sees it too. https://t.co/j6bZs3W6cH

— Pj Metz (@MetzinAround) August 19, 2026

De tels incidents expliquent l’apparition d’alternatives avec une concentration sur l’affranchissement à la dépendance de la centralisation

La plupart des projets open-source sont généralement hébergés sur GitHub ou d’autres alternatives comme GitLab. Bien que ces plateformes offrent de nombreux avantages et fonctionnalités (sans parler de la visibilité potentielle), elles présentent également des inconvénients comme ceux qui font surface avec cette récente panne sur GitHub. Par exemple, le projet youtube-dl a été retiré par Microsoft suite à une demande de retrait DMCA. Avec une approche centralisée, les équipes de développement n’ont pas de contrôle total sur leur projet.

C’est là qu’entrent en jeu des projets open source comme Radicle. C’est une alternative pair-à-pair (P2P) à GitHub construite sur Git. Radicle utilise un réseau décentralisé où les données sont stockées et répliquées directement sur les machines des utilisateurs.

Bien que Git soit conçu d’une manière ou d’une autre pour les interactions peer-to-peer, aucun déploiement ne fonctionne de cette façon. Tous les déploiements utilisent le modèle client-serveur car Git ne dispose pas de fonctionnalités permettant d'être déployé tel quel dans un réseau peer-to-peer. De plus, difficile de vérifier que le référentiel que vous avez téléchargé après un « clone git » est celui que vous avez demandé, ce qui signifie que vous devez cloner à partir d'une source fiable (c'est-à-dire un serveur connu). Une situation difficilement compatible avec P2P.

Radicle résout ce problème en attribuant des identités stables aux référentiels qui peuvent être vérifiés localement, permettant ainsi aux référentiels d'être servis par des parties non fiables.

En gros, Radicle favorise la collaboration sans intermédiaires entre les équipes de développement informatique tandis que GitHub nécessite une plateforme centralisée pour la collaboration. En l'utilisant, les développeurs n'auraient pas subi la panne de GitHub (qui a bloqué les Pull Requests et les API pendant des heures), grâce à une architecture sans point de défaillance unique.

Même sans connexion Internet active ou en cas de panne mondiale d'un hébergeur, vous pouvez continuer à créer des branches, valider du code et rédiger des correctifs localement. Dès que la connexion au réseau P2P est rétablie, vos modifications se propagent naturellement auprès des autres développeurs.

Et vous ?

Comment avez-vous vécu la panne mondiale sur GitHub en tant que développeur informatique ? Quelles sont les dispositions que votre entreprise a prises ? Partagez vos anecdotes
Pensez-vous que les projets open-source devraient explorer davantage les alternatives peer-to-peer comme Radicle ? Pourquoi ou pourquoi pas ?
Avez-vous déjà utilisé Radicle ou envisagez-vous de l’essayer pour vos projets ?

[qvignaud]

Je vais pas critiquer particulièrement GitHub, parce-que honnêtement les pannes ça arrive, et gérer de tels incidents sur une plateforme aussi grosse n'est clairement pas à la portée de tous.
On peut toujours regarder Microsoft avec des gros yeux, mais bon, si le consommateur vote avec son portefeuille, le tech vote avec ses outils. Si on continue d'utiliser GitHub, c'est qu'on accepte ce qu'en fait Microsoft.

Je me permet de mentionner le système Cadence.CI¹, qui permet de s'abstraire de la plateforme d'hébergement de code pour la partie CI/CD, donc faciliter d'éventuelles migrations entre GitHub, GitLab, Gitea, ou autre (y compris sans Git) et même de valider et lancer les pipelines sur et depuis la machine locale (donc si y'a panne de l'hébergeur de code, on peut toujours bosser en mode dégradé en ayant la CI sous la main).
Ça ne résoud pas tout, il y a surtout plein d'autres avantages, mais à un moment on parle des problèmes de reposer sur un service centralisé qu'on ne maîtrise pas comme GitHub.

¹ Dont je suis cofondateur, je cache pas le côté promo, mais à un moment quand on a une solution faut la donner.

[Anthony]

Le 17 août, alors que le trafic atteignait un nouveau pic, GitHub a connu une panne qui a duré 7 heures et 47 minutes, voici ce qui s'est passé, d'après le CTO de Github, Vlad Fedorov

Un pic de trafic survenu le 17 août 2026 a mis en évidence une faille critique dans l'infrastructure de GitHub, provoquant une panne de 7 heures et 47 minutes qui a perturbé plusieurs services de la plateforme à l'échelle mondiale. Selon Vlad Fedorov, le directeur technique, la panne a pris naissance dans un centre de données situé au cœur des États-Unis et a été aggravée par une boucle de réessais qui a saturé les systèmes au milieu de la procédure de rétablissement. Fedorov a qualifié cet incident de deuxième défaillance majeure de la plateforme en un mois, après une panne de GitHub Actions survenue le 6 août dernier. Il a précisé qu'aucune de ces deux pannes n'avait été causée par une modification du code, mais par un système qui n'avait pas su s'adapter à l'augmentation du volume de commits, qui a plus que doublé depuis avril.

GitHub est une plateforme propriétaire destinée aux développeurs qui leur permet de créer, stocker, gérer et partager leur code. Elle utilise Git pour assurer un contrôle de version distribué, et GitHub propose lui-même des fonctionnalités de contrôle d'accès, de suivi des bogues, de gestion des demandes de nouvelles fonctionnalités, de gestion des tâches, d'intégration continue et de wikis pour chaque projet. GitHub, dont le siège social est situé à San Francisco, est exploité par GitHub, Inc., une filiale de Microsoft depuis 2018.

Le 17 août 2026, GitHub a subi une nouvelle panne mondiale d'une durée de près de huit heures. L’incident a débuté vers 15 h 40 en France métropolitaine, puis a été déclaré résolu à 23 h 15. L’entreprise a attribué cet incident à un dysfonctionnement de l'autoscaling, ainsi qu'à une vague de tentatives de reconnexion dans VS Code. Ces tentatives répétées ont intensifié la pression sur une infrastructure déjà surchargée, aggravant ainsi les défaillances sur l’ensemble de la plateforme. La panne a touché les API, les pull requests, les webhooks, GitHub Actions et l'authentification. Au plus fort de l'incident, GitHub a signalé un taux d'erreur d'environ 20 % pour le trafic Web et API, et un taux stupéfiant de 50 % pour les téléchargements bruts de dépôts et d'archives. Cet panne a mis en évidence les inconvénients de la centralisation de la chaîne de valeur DevOps.

Dans un communiqué publié le 20 août 2026, Vlad Fedorov, directeur des technologies de GitHub, a détaillé la panne ayant perturbé les services et présenté les mesures engagées pour renforcer la fiabilité de la plateforme. Voici le communiqué de Vlad Fedorov : «

Le 17 août, GitHub a subi une panne qui a duré 7 heures et 47 minutes. Celle-ci a perturbé le fonctionnement de github.com, de l’authentification, de GitHub Actions, des API, des pull requests, des tickets et de Copilot, affectant ainsi les développeurs et les organisations du monde entier. Si vous essayiez de déployer un logiciel ce jour-là, nous vous avons déçus.

Il s’agissait de notre deuxième incident majeur en août, après une défaillance de GitHub Actions le 6 août. En mars et avril, je vous avais fait part des travaux en cours visant à améliorer la fiabilité de GitHub. Nous avons réalisé des progrès, mais ces incidents montrent clairement que nous devons accélérer ces efforts.

Ce qui s'est passé

Notre enquête a révélé que la panne a commencé lorsque le trafic a atteint un nouveau pic et qu'un composant critique de l'infrastructure de notre centre de données situé dans le centre des États-Unis n'a pas réussi à s'adapter à cette augmentation. La pression sur la capacité qui en a résulté s'est propagée à l'ensemble de nos systèmes, provoquant des échecs d'authentification et perturbant plusieurs services GitHub.

La remise en service a nécessité plusieurs actions coordonnées. Les équipes ont redirigé le trafic, isolé les infrastructures concernées et rétabli les services par étapes. La plupart des services GitHub ont été rétablis plus tôt dans la journée, mais certains services Copilot ont pris plus de temps. Des erreurs au sein de ces services ont déclenché une boucle de réessais côté client qui a entraîné une augmentation du trafic pendant la remise en service. Nous avons dû atténuer ce comportement avant de pouvoir rétablir le trafic en toute sécurité. L'analyse complète des causes profondes comprend une chronologie technique détaillée.

Aucune de ces deux pannes n'a été causée par une modification du code ou de la configuration. Ces deux incidents étaient essentiellement dus à des problèmes de capacité. Nous n'avons pas su faire évoluer les composants critiques avant que la demande ne dépasse leur capacité. Depuis avril, le nombre de commits mensuels est passé de 1,4 milliard à 2,9 milliards. Cette croissance explique la pression exercée sur nos systèmes, mais elle ne justifie en rien ces pannes.

Ce que nous avons fait et ce qui nous attend

Dans le cadre des engagements en matière de fiabilité que nous avons pris en début d’année, nous nous sommes concentrés sur trois priorités : augmenter la capacité, améliorer l’efficacité et éliminer les goulots d’étranglement architecturaux. Depuis, nous avons ajouté plus de 3 millions de cœurs de processeur, 120 pétaoctets de stockage haut débit et une capacité réseau considérable. Nous avons installé autant de matériel que la puissance disponible le permettait dans nos centres de données existants, tout en accélérant notre migration vers Azure.

Aujourd’hui, Azure prend en charge environ 58 % de la charge de la plateforme GitHub et la moitié de toutes les opérations Git, contre 12 % de la charge de la plateforme en mai. Cette présence accrue a également soutenu la croissance du nombre d’exécutions de tâches GitHub Actions, comme le montre le graphique ci-dessous.

L'infrastructure et la capacité d'Azure ont également permis d'accélérer nos travaux visant à faire évoluer les plus grands monorepos. Notre prochaine étape consiste à mettre en place une architecture dont la capacité de lecture évolue de manière linéaire en fonction du nombre de lecteurs, ce qui permettra d'effectuer un nombre illimité d'opérations de lecture. Nous la déploierons progressivement, en commençant par les plus grands monorepos.

L'échelle n'est pas notre seul défi. À mesure que le rythme et la complexité des changements s'intensifiaient, nos pratiques opérationnelles existantes ne suivaient plus. Nous avons réorienté nos équipes et nos ressources vers la disponibilité et investi dans des tests plus rigoureux, des déploiements plus sûrs, une meilleure observabilité et des alertes plus efficaces. Nous avons fait des progrès, mais ce travail n'est pas terminé.

Par ailleurs, nous isolons également les systèmes critiques et supprimons les dépendances partagées entre eux. Ce travail vise à réduire le risque de panne et à limiter son impact lorsqu’elle survient.

Nous tirons les leçons de chaque panne et intégrons de nouvelles tâches à notre programme de travail dédié à la disponibilité. Les incidents survenus les 6 et 17 août ont donné lieu à deux changements immédiats. Premièrement, nous appliquons des limites de tentatives de réessai, des budgets de réessai et des délais d'expiration variables cohérents pour toutes les interactions entre services, afin d'éviter les « tempêtes de réessais » et les effets en cascade sur la charge. Deuxièmement, nous réexaminons les alertes de moindre priorité liées au processeur et à la mémoire afin d'identifier les composants susceptibles de tomber en panne lors de pics de trafic soudains.

Notre engagement en faveur d'une haute disponibilité n'est pas seulement une promesse technique. La communauté des développeurs compte sur GitHub pour créer, publier et exploiter ses projets. Cela n'est possible que si vous pouvez compter sur nous, ce qui n'a pas été le cas le 17 août. Il est de notre responsabilité d'y remédier. Nous regagnerons votre confiance grâce à l'évolutivité et à la fiabilité de la plateforme. »

Vlad Fedorov, CTO de GitHub

À propos de Vlad Fedorov

Vladimir Fedorov est directeur technique chez GitHub. Il apporte plusieurs décennies d’expérience dans le domaine du leadership technique et de l’innovation. Fervent défenseur de la productivité des développeurs, Vlad Fedorov dirige l’équipe d’ingénierie de GitHub afin de façonner l’avenir des outils de développement et de l’innovation, en adoptant une approche centrée sur les développeurs.

Avant de rejoindre GitHub, Vlad Fedorov a cofondé UserClouds, une start-up spécialisée dans la gouvernance des données et la protection de la vie privée. Il a passé 12 ans chez Facebook, désormais Meta, en tant que vice-président senior, où il a dirigé des équipes d’ingénieurs comptant plus de 2 000 personnes dans les domaines de la protection de la vie privée, de la publicité et de la plateforme. Au début de sa carrière, Vlad Fedorov a travaillé chez Microsoft et a obtenu une licence et un master en informatique à Caltech. Il siège actuellement au conseil d’administration de Codepath.org, une organisation qui se consacre à la refonte de l’enseignement supérieur afin de former la première génération d’ingénieurs, de directeurs techniques et de fondateurs natifs de l’IA. Vlad Fedorov vit dans la région de la Baie de San Francisco et, lorsqu'il ne travaille pas, il aime passer du temps en plein air et sur l'eau avec sa famille.

Source : Communiqué de GitHub

Et vous ?

Quel est votre avis sur le sujet ?
Trouvez-vous cette initiative de GitHub crédible ou pertinente ?

Voir aussi :

Suite aux récentes pannes de GitHub, OpenAI développe son propre référentiel de code rival de GitHub et envisage de le mettre à la disposition des clients d'OpenAI, en concurrence directe avec Microsoft

Les grandes entreprises en urgence après une attaque sur GitHub ayant exposé leurs données sensibles, l'incident révèle les limites de la sécurité dans l'open source actuel

GitHub sous tension : certains utilisateurs mécontents se rebellent contre les fonctionnalités IA Copilot imposées, quand l'aide optionnelle au codage se transforme en prison numérique

GitHub n'est plus indépendant de Microsoft, son PDG Thomas Dohmke démissionne et ne sera pas remplacé, GitHub sera ainsi directement intégré à l'organisation Microsoft

[Anselme45]

github? github? github?

c'est bien LE github qui a été racheté par une certaine boite nommée "microsoft" en octobre 2018?

Qui a dit que tout ce que touchait microsoft finissait par se transformer en "m..." (un mot scatologique de 5 lettres)?

[Freem]

Hé oui, Microsoft, c'est un peu comme Midas, mais avec la matière fécale en guise d'or. D'ailleurs, les deux noms commencent pareil, c'est voulu, ou pas?