Microsoft dénombre plus d’un million d’utilisateurs payants de l’extension GitHub Copilot d’OpenAI
Le 30 octobre 2023 à 08h00
1 min
Sciences et espace
Sciences
Le nombre d'utilisateurs payants de Github Copilot, l'extension développée par OpenAI pour aider les développeurs en complétant automatiquement leur code, a augmenté de 40 % au cours du dernier trimestre, rapporte ZDNet.
« Nous dénombrons plus d'un million d'utilisateurs payants de Copilot dans plus de 37 000 organisations abonnées à Copilot pour les entreprises », a déclaré le CEO de Microsoft, Satya Nadella, « avec une traction significative en dehors des États-Unis ».
Le New York Times précise que l'entreprise a réalisé un chiffre d'affaires de 56,5 milliards de dollars, en hausse de 13 % par rapport à l'année précédente. Son bénéfice a atteint 22,3 milliards de dollars, en hausse de 27 %, dépassant les attentes des analystes et les propres estimations de Microsoft.
Microsoft, qui a investi 13 milliards de dollars dans OpenAI, ne s'attendait initialement à un retour sur investissement qu'au début de l'année 2024.
L'entreprise intégrera le mois prochain Copilot AI dans sa suite Office. Une fonctionnalité d'ores et déjà testée par 40 % des entreprises du classement Fortune 100.
Le 30 octobre 2023 à 08h00
Commentaires (21)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 30/10/2023 à 10h10
Ce qui est rigolo, c’est que j’ai vu passer il y a quelques jours que Microsoft perdrait en moyenne 20$/utilisateur/mois pour les utilisateurs de copilot. Après, c’était du conditionnel.
Du coup, il serait intéressant de savoir si le retour sur investissement est lié ou non à Github (car bon sur le brief de 5 paragraphes, 2 le concernent).
Et j’ai du mal à voir Copilot AI (pas encore déployé) comme participant à ce retour sur investissement, ni même Bing (gratuit)
Le 30/10/2023 à 12h37
L’expression n’est pas fondamentalement fausse, mais un poil maladroite. GitHub Copilot est issu un partenariat entre GitHub et OpenAI (avant même celui avec Microsoft) et le modèle de celui-ci est Codex. Codex est un modèle fine-tuned basé GPT-3 spécialisé pour produire du code informatique.
J’avais vu aussi cette info, et ça m’a fait mettre en perspective l’insistance de Microsoft pour vouloir nous le faire prendre. Sauf qu’en l’état, j’ai eu des retours très contrastés d’une expérimentation de GitHub Copilot par des devs à qui on a donné l’accès. Cela allait du “utile, efficace” à “j’ai perdu mon temps avec”. Et de ma fenêtre, pour moi l’actuel Copilot est une auto-completion de luxe. Je préfère largement ChatGPT.
Par contre, Copilot Chat est beaucoup plus intéressant (et je l’ai testé). Et vu les quelques présentations que j’ai pu avoir par MS ou GitHub sur celui-ci, l’intégration à la plateforme promet d’être intéressante. Mais clairement il sera pas à 10\(/19\) pour les personal et business accounts. Copilot Chat risque d’être plus cher je pense car vu la taille des contextes qu’il manipule, il doit coûter une blinde à l’usage.
Au sujet de l’intégration des diverse “Copilot” de Microsoft, je pense qu’ils tentent la carte de l’économie d’échelle en diluant et mutualisant l’usage des modèles pour espérer que ce soit un poil rentable avec du premium en soutien. Clairement, l’IA générative coûte encore très cher à faire tourner à l’échelle (suffit de voir le pricing côté Azure Open AI pour s’en rendre compte - concernant les tokens considérez que 1000 tokens c’est environ 750 mots anglais)).
Le 30/10/2023 à 12h34
Je ne suis pas inquiet. MS présentera Copilot aux entreprises comme un moyen d’être plus performantes… Ce que les entreprises traduiront par pouvoir réduire leurs équipes de dev sans perdre en productivité. Et hop.
Le 30/10/2023 à 12h38
Pour le coup, c’est pas le discours qu’ils portent.
Le 30/10/2023 à 12h46
J’utilise Copilot depuis 2 - 3 mois (en plugin dans PHPstorm) et franchement je me vois mal m’en passer maintenant.
Je paie 10€ / mois, je n’ai aucun doute que le tarif va fortement augmenter (comme d’hab).
Le 30/10/2023 à 12h50
Ma question ne portait pas sur le futur, mais sur le passé. A part Github Copilot, quels sont les services utilisant OpenAI qui aujourd’hui, peuvent rapporter à Microsoft ? (j’exclue volontairement tout ce concerne Azure, le brief n’en parlant pas et se focalisant sur Github)
Le 30/10/2023 à 12h54
J’utilise Copilot depuis plusieurs mois maintenant. C’est un gros plus, j’avoue.
Pour faire du code chiant et répétitif, il est assez efficace.
Quand on pratique un nommage correct des fonctions, il a tendance à balancer un squelette qui n’est pas trop mauvais (mais souvent avec quelques retouches quand même).
Pour des trucs beaucoup plus poussés, je passe aussi par ChatGPT, qui va me donner une trame. C’est comme ça que j’ai fais pour réaliser un client SFTP ou pour parser des paramètres de ligne de commande (ce que je n’avais pas fait depuis des lustres !). Cela donne en quelques secondes des bibliothèques utilisables, un exemple de code plus ou moins fonctionnel.
Pour ma part, j’ai gagné en productivité en l’ayant. Donc pour 10€/mois, il est clair que je ne suis pas prêt de m’en passer (et même pour 20 !). Voilà, petit retour d’expérience ;)
Le 30/10/2023 à 14h09
Merci pour le retour d’XP. Je pense que pour des devs expérimentés il peut effectivement avoir un intérêt dans sa version actuelle car il fait gagner du temps. Par contre pour l’assistance à la conception et la fourniture d’un guide, typiquement j’ai vu celui de Copilot Chat qui est similaire à ChatGPT.
Typiquement, il propose lui-même une trame où un peu comme Bing Chat, il propose les questions suivantes. Et sur le projet de test que j’avais fait, elles étaient plutôt logiques et avançaient d’une manière itérative graduelle.
Je vois aussi ce genre de travers, et pour le coup je ne pense pas que ce soit les liés aux outils. Ces problèmes d’organisation sont purement humains et issus de manager qui considèrent l’IT comme un coût et non un investissement.
Je reviens cependant sur ma réponse qui était un peu trop simpliste : Oui, Microsoft te vend GitHub Copilot comme un outil de productivité et te permet même d’estimer un ROI avec une matrice de calcul (et grosso merdo, il revient à environ 0.5 ETP dans les estimations que j’ai pu avoir). Mais in fine, ils ne vendent pas ça en tant que remplaçant des devs, c’est même le discours inverse et globalement celui qu’ils ont sur l’IA (et je le trouve plutôt cohérent malgré le bullshit ambiant usuel) mais bien comme outil d’accompagnement.
Typiquement, je considère le Copilot actuel comme peu utile de ma fenêtre car je ne suis pas dev. J’ai du mal à l’utiliser et ne vois pas en quoi il m’aide par rapport à mes activités. Et ayant testé sa version Chat, clairement un non dev ou encore un junior ne sauront pas l’utiliser. Et dans tous les cas, Copilot reste sujet aux limitations des LLM. Typiquement, si on travaille dans une techno récente, il risque de n’être d’aucune aide car inconnue ou méconnue de son modèle.
Bref, remplacer un dev par Copilot, c’est comme remplacer un dev par du copier/coller Stackoverflow : merde absolue garantie.
Le 30/10/2023 à 21h14
Avis de ma pratique.
GitHub Copilot Chat est “en retard” par rapport à “Bing GPT”. Moins pertinent, comprend moins bien ce que je veux (à question “copier/coller”). Mais, ça ne veut pas dire que dans l’avenir ce ne serait pas mieux.
Sinon l’extension d’assistance de saisie de code, comme dit par d’autres c’est un bonheur pour tout ce qui est un peu répétitif, qui suit un schéma qu’il va pouvoir prédire. Si le nommage est rigoureux et carré, il fait des merveilles. Que ce soit du code “métier” ou le codes des tests.
Sinon, faut quand même faire très attention. Surtout dans des métiers qu’il “connait” (genre facturation, tiers, etc…). Il propose facilement beaucoup de ligne de code et souvent l’erreur se mets dans les détails :) Donc super utile mais pour moi, faut bien relire ce qu’il propose :)
Le 30/10/2023 à 13h10
quand j’ai commencé le dev, il y avait des postes distincts pour chaque activité du SDLC: requirements, design, code, test, deployment, support.
Avec la magie des méthodes agiles et des outils devops, ces activités ont été réassignées à des profils plus polyvalents… avec à la clé une réduction des effectifs, justifiée par le fait que tout le monde peut (et doit savoir) tout faire. Donc embauche de gens qui ont des profils “devops” et qui sont interchangeables sur le planning.
Je vois lest outils IA comme la continuation de cette tendance: ca sera plus facile pour tout le monde de faire des choses => on aura moins besoin d’avoir des profils spécialisés => on va pouvoir optimiser le pool de ressources humaines nécessaires.
Exemple (indirect): ma boite regarde pour prendre l’option IA qui fait le résumé des réunions Teams. Ca libérera du temps pour la ressource qui faisait ce job. Donc il aura davantage de temps dédié à faire de l’opérationnel… donc moins besoin d’embaucher un dev en plus dans l’équipe.
Le 30/10/2023 à 13h13
Merci. Je ne connaissais pas cet usage ;)
Petit troll : vu le temps requis pour se servir de teams (rien que pour l’ouvrir), cette fonctionnalité devrait être offerte !
Le 30/10/2023 à 14h31
Pour que le service soit adopté par les opérationnels Ms fait bien attention a ne pas le vendre comme étant un moyen de perdre son emploi.
Mais dans les faits, le top management/finance voit bien le potentiel du truc… D’un point de vue purement comptable - le seul qui compte pour eux - , si une équipe de 5 personnes à temps plein (5x100%) peut voir sa charge de travail allégée de 20% avec l’IA (=> 5x80%) alors elle peut être avantageusement remplacée par une équipe de 4 (5x80% = 4x100%).
Je pourrais faire le parallèle avec les outils “office” et le personnel de secrétariat:
Y a 30 ans t’avais un secrétariat pour chaque service/secteur de l’entreprise. Avec des secrétaires trilingues qui faisait du 40 mots/minute.
Maintenant, t’as juste un secrétariat général multi-service (avec effectif réduit). L’ancien secrétariat c’est toi qui le fait, avec word/outlook et deepl. Et c’est du boulot à faire en plus de ton coeur de métier.
Le 30/10/2023 à 16h39
Pour faire un autre parallèle avec un métier qui était censé disparaître, celui d’admin sys avec le Cloud. C’était annoncé en grande pompe un peu partout. Au final on a toujours des admin système … Ils ont juste été renommés avec un nom un peu plus fancy (“cloud ops”, “sys ops”, ou encore
mouton centipede“devops”, et désormais “platform engineer”).Au même titre que j’ai aussi connu l’externalisation à outrance de l’IT où on te faisait comprendre que t’étais bien gentil et mignon, mais qu’un indien c’était moins cher. Les clients que j’ai vu faire ça sont revenus à réinternaliser car ils n’avaient plus aucune connaissance de leur métier. Je dis bien de leur métier, même pas de leur IT. Quand un service IT compte 95% de presta, c’est déjà un problème en soit. Sauf que comme l’IT est un centre de coûts et non un investissement, 95% de presta c’est la possibilité de virer 95% de son personnel sans être emmerdé en cas de difficulté financière. C’est en ce moment le cas chez plusieurs grandes entreprises dans le Nord.
Et tout ça, c’est que des décisions de managers court-termiste, là dessus on est d’accord. Raison pour laquelle je considère que l’IA ne changera rien à ces décisions absurdes, elles auraient eu lieu de toute façon peu importe le nouveau truc à la mode.
Donc dans tous les cas, oui, l’IA va transformer et réduire la voilure de certains métiers. C’est évident et je l’ai déjà dit ici plusieurs fois et on a vu des articles en ce sens. Mais Copilot remplacer un dev, non, pas dans son état actuel.
Surtout quand on parle de modèles pre-trained, qui sont donc incapables de réellement créer de toute pièce et ont besoin d’une énorme quantité et variété de données pour être efficaces. Les études sur le sujet avaient justement évoqué la dégénérescence des LLM lorsqu’ils sont entraînés de manière consanguine. Donc en l’état actuel de l’IA générative, elle ne peut clairement rien remplacer puisqu’elle entraînera le même résultat qu’une externalisation de son IT : perte de connaissance et compétence.
Le 30/10/2023 à 16h17
hahaha oui clairement !
Tu as raison je pense.
Pour moi le gain représente bien plus de 20%, et ce après avoir compris qu’il fallait pas lui faire 100% confiance.
Les dev salariés ont un peu de soucis à ce faire. Sans compter qu’on est au début de la techno.
Parfois il me sort des noms de fichiers ou de variables (correctes) dont je me demande d’où il sort ça.
Quand j’ai plusieurs projet ouvert, il est capable de s’inspirer de tous les projets. Plus je l’utilise et moins il se goure et s’adaptant à mes habitudes.
Ce WE j’ai fait du dev Bash. Très très efficace ! encore plus qu’avec PHP.
Vraiment bluffant.
Le 30/10/2023 à 22h13
utilisateur au quotidien , ce qui m’étonnes c’est qu’il n’y est qu’un peu plus d’un million d’utilisateurs… j’utilise lextension d’assistance de code, pas le chat. J’utilise chat gpt4 a coté pour d’autres requêtes. Surtout pour aller plus loin sur des concepts que je ne connais pas encore, ca permet de se former plus rapidement et de tester des solutions logicielles. chat gpt n’a jamais la flemme de se tartiner des dizaines de lignes de code….
bref tout ca pour dire que je trouve ce chiffre très faible au vu de l’avantage que cela procure….
Le 31/10/2023 à 06h15
Il est encore en beta donc forcément il va s’améliorer. Après de ce que j’ai pu voir, il est basé sur GPT-4 et non Codex comme le Copilot actuel. Donc forcément y’a des différences je pense.
C’est même indispensable et là dessus que ce soit la comm de l’éditeur et l’outil en lui-même, ils insistent lourdement ce sur point.
J’ai pu constater moi-même la capacité de Copilot Chat à proposer un développement itératif en relation avec le besoin. C’était très cohérent, progressif, vraiment bien foutu. Sauf quand à un moment il s’est auto bloqué en me proposant une question suivante pour laquelle il a refusé de répondre
Le 01/11/2023 à 08h42
C’est quand-même fabuleux qu’en 2023 on dépense des milliards en IA génératives de code “chiant et répétitif” au lieu d’inventer une fois pour toutes un paradigme de langage de programmation (général et utilisable, s’entend, ne venez pas avec Lisp ou APL) ou une librairie qui n’a pas besoin de code chiant et répétitif…
[Histoire Personnelle]
En 1997 j’avais déja un outil ORM qui générait tout seul le code C++ et SQL à partir d’un fichier de description unique, et une règle dans le makefile pour regénérer à chaque changement du fichier description…
[/Histoire Personnelle]
Le 01/11/2023 à 09h27
Mais je t’en prie. Fait. Je pense que l’ensemble de la communauté des développeurs te remerciera ;)
Le code chiant et rébarbatif ne se limite pas à l’usage ou non d’un ORM. L’usage d’une API, le mapping entre des modèles différents, la gestion de règles métiers (parfois semblable mais légèrement différentes les unes des autres), la génération de documents, la communication backend/frontend … Bref, les exemples ne manquent pas.
Le 01/11/2023 à 10h14
OK, j’ai juste besoin de 30 milliards de dollars de la part d’investisseurs pas nécessairement pressés de revoir leur argent.
Blague à part, je constate simplement que chaque fois que j’ai du code chiant et répétitif à écrire, je me débrouille pour écrire autour du bouzin un script qui génère le code à ma place.
Et ce n’est pas que de l’ORM. J’ai notamment un truc qui, à partir d’un fichier unique qui représente des ressources système génère au besoin la documentation de l’API d’accès au format swagger, les tests de régression minimaux pour Postman, des librairies en js, c#, bash/curl et Python, une documentation au format md avec des graphiques de dépendance en mermaid, etc.
Notamment, je peux appeler des méthodes comme
AddParameterFields
ouAddPagination
qui sont des méthodes que je maîtrise totalement et qui font le boulot chiant et répétitif. Je ne vois pas Copilot faire ça à ma place.Et ce bazar est automatisé, je n’ai pas besoin d’avoir une extension dans mon éditeur… Je change une ligne dans le fichier de description et tous les fichiers dépendants sont regénérés au moment du build. C’est automatique, synchronisé et idiot-proof. Avec un minimum de soin, ça supporte les merge de branches dans git. Et je n’ai rien inventé, hein, c’est dans la veine de yacc, bison et lex. C’est pas loin des “infrastructure as code” pour déployer dans le cloud (terraform, etc.)
Ce genre de script me convient à moi, mais pas nécessairement à tout le monde, parce que ma façon de voir les choses (“tout l’environnement se décrit dans du code qui doit compiler”) ne correspond pas nécessairement aux attentes d’un développeur lambda. Je ne suis pas la personne idéale pour développer un tel outil général (mais je me propose éventuellement de le tester et de me plaindre abondamment car il ne me conviendra pas non plus ).
Le 01/11/2023 à 10h40
Demande a Elon. S’il a un moyen de virer 80% de ses devs, il sera peut être preneur (désolé pour le petit troll ^^)
Pour en revenir au sujet, certaines choses s’automatise très bien, d’autre non. J’ai l’impression que l’exemple que tu donnes concerne la génération d’une API. Effectivement, ce genre de truc, ça s’automatise très bien.
Par contre, la consommation d’une API beaucoup moins. La partie “appel” oui, mais lorsqu’il s’agit de faire le mapping entre les données reçus et la représentation en interne (un adapteur quoi) avec potentiellement des traitements plus ou moins lourd durant la conversion, ce genre de méthode montre très vite des limites.
Qu’on soit bien d’accord, j’automatise aussi ce que je peux automatiser. Mais il m’en reste… je fais justement pas mal de consommation d’API et d’interopérabilité avec d’autres systèmes d’informations, et chaque cas est différent et unique, avec ses propres spécificités. Le retour sur investissement d’automatiser ça avec un fichier de configuration ou de description (appelle le comme tu veux), n’aurait guère de sens. Ecrire un fichier de code ou un fichier de description, c’est plus ou moins la même tâche, sauf qu’il faudrait en plus se fader le convertisseur/générateur.
Par contre, j’aurais X fichiers de code à générer, oui, ça pourrait avoir sens dans ce cas.
Le 01/11/2023 à 14h14
C’est effectivement une API dont j’écris le code serveur et le code client, et qui utilise un ensemble assez restrictif de conventions (la clé s’appelle Id et c’est un GUID, si l’objet a un nom significatif pour l’utilisateur les champs s’appellent name, shortname, longname et sont toujours par trois, etc - ça aide). Le script automatise en outre la création/update/population des tables SQL, des opérations CRUD de base en plus des API de plus haut niveau, le tout avec les conventions d’appel qui vont bien pour le serveur et pour le client - le code métier peut appeler CreateResource() et selon que t’es dans le serveur ou le client ça fait un appel SQL ou un appel REST (je simplifie, mais tu vois le genre)… Si demain je choisis d’avoir un memcached quelque part, je change le générateur pour qu’il mette le code où il faut dans les appels CRUD (quand bien même ce ne serait qu’une injection de dépendance à quelques endroits)… Et oui une ligne de mon script de configuration génère du code dans 10 ou 12 fichiers différents.
Je n’ai de fait pas le besoin d’interroger une API que je ne contrôle pas moi-même, en tout cas pas dans les mêmes proportions. Dans les grandes lignes, je ne désespère pas d’arriver à décrire ces APIs dans ma structure existante, du moment qu’elles ne sont pas trop ésotériques ; json voire XML ou ASN.1, les dates en ISO8601 et pas dans le calendrier maya, ça devrait passer crème.
Bref comme on a dit, ma solution règle mon problème, pas le tien, et donc c’est pas demain la veille qu’on aura une solution globale. Ceci n’est que mon avis mais on aurait plus l’usage d’une IA qui génère un générateur de code que d’une IA qui génère du code…