Microsoft prévoit d’intégrer Python à Excel

 (theverge.com)
1 points par GN⁺ 2023-08-23 | 1 commentaires | Partager sur WhatsApp
  • Microsoft a commencé à proposer en préversion publique une fonctionnalité intégrée permettant l’analyse et la visualisation de données avec Python dans Excel
  • Il est possible d’accéder à Python depuis le ruban Excel sans installation séparée, puis d’affiner les résultats avec les formules, graphiques et tableaux croisés dynamiques existants
  • La nouvelle fonction PY expose les données Python dans la grille du tableur, et grâce à un partenariat avec Anaconda, il devient possible d’utiliser pandas, statsmodels, Matplotlib, etc. dans Excel
  • Les calculs s’exécutent non pas en local mais dans le Microsoft Cloud, puis reviennent dans la feuille de calcul, avec la possibilité de créer des visualisations basées sur Matplotlib et Seaborn
  • La préversion publique débute sur Windows dans le canal Beta de Microsoft 365 Insiders, et après la fin de la préversion, certaines fonctionnalités seront limitées sans licence payante

L’analyse Python arrive dans Excel

  • Microsoft ajoute une intégration de Python à Excel, permettant de manipuler et d’analyser des données directement dans le tableur
  • Les utilisateurs peuvent accéder directement à Python depuis le ruban Excel et poursuivre des travaux d’analyse avancée sans quitter l’environnement familier d’Excel
  • Les graphiques créés avec Python et les résultats des bibliothèques peuvent être combinés avec les formules, graphiques et tableaux croisés dynamiques d’Excel pour être affinés davantage

Un fonctionnement intégré, sans installation séparée

  • L’intégration de Python est proposée dans le cadre du connecteur intégré d’Excel et comme partie de Power Query
  • Elle est accessible sans installation de logiciel supplémentaire ni configuration d’extension distincte
  • La nouvelle fonction PY expose les données Python dans la grille du tableur Excel

Bibliothèques Anaconda et visualisation

  • Microsoft collabore avec Anaconda, dépôt Python pour l’entreprise, afin de permettre l’usage des principales bibliothèques Python dans Excel
  • Les bibliothèques disponibles incluent notamment
    • pandas
    • statsmodels
    • Matplotlib
  • Les utilisateurs d’Excel peuvent créer des formules, des tableaux croisés dynamiques et des graphiques à partir de données Python
  • Des bibliothèques de visualisation comme Matplotlib et Seaborn permettent de générer les représentations suivantes
    • heatmap
    • violin plot
    • swarm plot

Les calculs sont traités dans Microsoft Cloud

  • Le code Python est écrit et utilisé dans la feuille de calcul Excel, mais le traitement des calculs s’effectue non pas dans Excel en local, mais dans le Microsoft Cloud
  • Les résultats d’exécution sont ensuite renvoyés dans la feuille de calcul Excel

Portée de disponibilité et conditions de licence

  • La préversion publique de Python dans Excel est proposée dans le canal Beta de Microsoft 365 Insiders
  • La disponibilité initiale est limitée à Windows
  • Microsoft prévoit ensuite d’étendre la fonctionnalité à d’autres plateformes
  • Pendant la période de préversion, elle est incluse dans l’abonnement Microsoft 365
  • Après la fin de la préversion, certaines fonctionnalités seront limitées sans licence payante

À lire aussi

1 commentaires

 
GN⁺ 2023-08-23
Avis sur Hacker News

  • Pour avoir travaillé autrefois comme développeur Excel et tenté sans succès d’intégrer Python à Excel, cette annonce est aujourd’hui une agréable surprise.
    Il y a environ 7 ans, j’ai eu l’occasion de quitter l’équipe Excel, mais le responsable de mon responsable a appris que je voulais intégrer Python à Excel et m’a dit que, si je restais, il me confierait ce travail. Ce que je pensais être un chantier de 6 mois est devenu un projet d’environ 3 ans, et le volet Python s’est estompé pour finalement sortir sous la forme de fonctions personnalisées JavaScript dans Excel.
    Python aussi s’exécutait « dans le cloud », sur la base d’AzureML v1, mais il y avait des discussions sur une exécution locale ou non. Il y a eu des réorganisations, des relancements, des recrutements à nouveau et des départs de PM dans l’équipe partenaire AzureML, puis une autre équipe partenaire s’est rendu compte qu’elle pouvait utiliser notre code pour exécuter JavaScript dans un processus externe, si bien que nous avons passé beaucoup plus de temps à lancer cette fonctionnalité que Python.
    Le travail central consistait à modifier le moteur de calcul d’Excel pour permettre aux fonctions de faire des calculs asynchrones, afin que l’utilisateur puisse continuer à travailler sur d’autres parties de la feuille de calcul pendant qu’un endpoint distant — JavaScript, Python ou autre — effectuait le calcul. Avant, la feuille de calcul était verrouillée pendant le calcul, ce qui n’était pas idéal pour les calculs longs et à durée indéterminée. Je me demande si une partie de ce que nous avons construit se retrouve dans cette fonctionnalité.
    « Recalc or die »

    • Grâce aux fonctions JavaScript asynchrones, il a été possible de lancer des fonctions personnalisées stables avec xlwings et Python.
      Le problème d’Office.js, c’est que pour l’utilisateur Excel moyen, la masse de dépendances npm rend le démarrage beaucoup trop difficile, et même les développeurs professionnels galèrent pas mal. Je suis content d’avoir fait en sorte que les utilisateurs n’aient pas besoin d’utiliser Node.js : https://docs.xlwings.org/en/latest/pro/server/officejs_custo...
    • Il y a quelques années, j’avais déjà créé un « Python dans Excel » fonctionnel, et SQL ainsi que Matlab/R s’exécutaient aussi à distance.
      C’est un projet que j’ai abandonné aujourd’hui : https://alphawolfxl.com/
      Quelques personnes à qui j’avais demandé de tester la bêta m’ont dit que « leur entreprise ne paierait pas », ce qui m’a donné l’impression d’avoir perdu mon temps, alors j’ai arrêté. En voyant ça maintenant, j’ai des sentiments mitigés.
    • Je me demande pourquoi Microsoft n’a pas produit de bons exemples pour cette nouvelle technologie. Les rares exemples fournis ne s’adressent qu’aux programmeurs.
      Globalement, il manque du vrai code fonctionnel permettant de voir comment JavaScript fonctionne dans Excel ; pour l’instant, ça donne presque l’impression d’un tutoriel du type « comment dessiner une chouette ».
    • Nous utilisons des fonctions personnalisées JavaScript pour appeler notre API d’analyse interne, et c’était plutôt agréable à utiliser.

  • J’aimerais que cela prenne aussi en charge l’exécution locale de Python, et pas seulement Microsoft Cloud, mais cette seule fonctionnalité pourrait déjà moderniser Excel de manière importante.
    Cela pourrait même supprimer le besoin de sites web destinés à afficher ce genre de données. Dans un ancien poste, j’avais créé un site web d’analyse utilisé seulement par quelques personnes en interne ; si cette fonctionnalité avait existé à l’époque, elle aurait probablement suffi à le remplacer.

    • Chaque fois que j’en parle, je me heurte à une résistance. Les utilisateurs veulent simplement analyser librement leurs données dans Excel, tandis que l’IT dont je fais partie veut construire une web app pour le faire à leur place. Au final, les utilisateurs ne sont pas satisfaits, parce que ce qu’ils voulaient au départ, c’était Excel.
      J’explique sans cesse qu’il suffit de créer un datamart avec SQL Server et de l’alimenter avec les données nécessaires à l’analyse via un outil ETL. Il n’est pas nécessaire de leur donner accès aux données sources. Pourtant, tout le monde me regarde bizarrement, et préfère lancer un projet Tableau à plusieurs millions de dollars. Les utilisateurs n’en veulent pas, c’est vraiment aberrant.
    • Je travaille dans l’équipe Excel. Si vous pouvez résumer pourquoi c’est important et l’envoyer à bgruenbaum@microsoft.com, je le transmettrai aux PM.
      Sinon, vous pouvez aussi l’envoyer via l’interface de feedback d’Excel web/desktop. Les PM lisent tous ces retours.
    • Il y a plusieurs raisons importantes de l’exécuter dans des conteneurs isolés par hyperviseur sur Azure, sans accès à Internet.
      Cela permet de garantir une expérience cohérente à tous les utilisateurs. Quand on imagine devoir maintenir chacun sa distribution Python locale et garantir son fonctionnement avec Excel au fil du temps, alors que les versions divergent, c’est un cauchemar.
      Cela permet aussi qu’un classeur Excel partagé avec d’autres utilisateurs se calcule tout simplement. Si cela dépend d’installations Python locales toutes différentes, ce ne sera pas le cas, et les utilisateurs seront très frustrés.
      La sécurité compte aussi beaucoup. Il suffit d’imaginer ouvrir un fichier Excel capable d’exécuter du code Python avec les droits de l’utilisateur local.
      Je suis aussi entièrement d’accord avec le deuxième point. Créer en Python des applications internes qui s’intègrent à l’infrastructure IT existante est, au mieux, frustrant. Excel fait déjà partie de l’infrastructure IT presque partout, et c’est un canevas réactif programmable.
      Divulgation : je travaille dans l’équipe de conception de cette fonctionnalité.
    • Le fait que cela s’exécute dans Microsoft Cloud pourrait justement le rendre plus utile que les macros dans notre entreprise.
      Ici, les macros sont vues comme un moyen d’exécuter des malwares sur les machines clientes, et leur utilité n’est pas jugée suffisante pour accepter ce risque.
    • Le limiter au cloud se défend dans une certaine mesure. Si Python devient une partie centrale du format de fichier Excel, cela pourrait réduire la portabilité et créer toutes sortes de problèmes de compatibilité à l’avenir.

  • On voit clairement des signaux d’alerte ici. La force fondamentale d’Excel vient du fait qu’un classeur peut exister de façon autonome, mais désormais le processus sera lié au cloud pour toujours
    Dans trois ans, quand il faudra ouvrir le classeur d’un collègue décédé, cela dépendra du fait que le fournisseur continue ou non à prendre en charge cette intégration
    C’est terrible quand, pour n’importe quelle tâche, la première étape devient « trouver comment refaire fonctionner le logiciel ». Au cours des dernières décennies, je l’ai vécu plusieurs fois avec toutes sortes de compléments pour Excel, Outlook et Word, et ces compléments ne faisaient même pas le traitement à distance

    • « Vous ne posséderez rien, mais vous serez heureux » s’étend maintenant jusqu’aux feuilles de calcul. Même ce qu’on produit comme salarié devant son bureau, on ne le possédera plus
    • Honnêtement, ça semble plus facile à gérer de cette façon. Comme ils utilisent la distribution Anaconda, s’ils lient chaque classeur à une distribution précise et prévoient des possibilités de mise à jour/retour arrière, ce sera bien plus simple que de gérer des installations locales
    • Ce n’est pas seulement lié au cloud, mais aussi à un abonnement. Si vous résiliez l’abonnement, si vous n’avez pas celui dont la présentation disait qu’il pourrait correspondre à un module payant, ou si votre Excel vous est fourni par un prestataire et que vous n’avez pas d’abonnement, l’utilisation de cette feuille Excel pose déjà problème
    • Depuis environ sept ans, je n’ai pas utilisé de tableur qui ne soit pas dans le cloud. Cela dit, je n’utiliserais pas Excel pour des travaux importants et à longue durée de vie. Je m’en sers surtout pour du brainstorming ou pour intégrer des captures d’écran dans des présentations
    • Que l’on utilise le cloud ou non, ce problème existe déjà. Les feuilles Excel peuvent déjà contenir des liens externes vers le Web ou d’autres fichiers, et si cette ressource Web ou ce fichier n’existe plus, c’est fini. Les vieux fichiers peuvent aussi ne s’ouvrir qu’avec des logiciels qui ne fonctionnent plus sur les machines modernes
      C’est pourquoi il est important, de temps en temps, de réellement restaurer ses sauvegardes ou, dans ce genre de cas, de vérifier les fichiers importants

  • J’étais enthousiaste à propos de « Python dans Excel », puis je me suis refroidi en voyant la mention « exécuté dans le cloud ». Je ne vois pas vraiment d’autre raison que de nous enfermer dans un service cloud. Ça ressemble beaucoup trop à l’idée de me protéger contre une encre d’imprimante dangereuse
    En général, j’aime les produits MS Office et j’ai tendance à les voir d’un bon œil. S’il existe une bonne raison crédible, autre que l’enfermement, d’exiger que Python s’exécute dans le cloud, j’aimerais la connaître

    • Signal d’alerte. M$ pousse les gens vers son cloud. La façon dont OneDrive intercepte le système de fichiers local est un bon exemple que beaucoup ont déjà subi
      À mon avis, il aurait déjà fallu quitter M$ il y a environ cinq ans. Tous leurs produits, de Windows à Office, intègrent déjà des fonctionnalités anti-consommateur
    • Ne pas demander aux clients de gérer une installation locale de Python peut être une raison
      Bien sûr, je comprends aussi que les utilisateurs avancés d’Excel+Python sont probablement habitués à apporter et maintenir leur propre runtime Python
    • C’est sans doute parce que la plupart des utilisateurs d’Excel n’ont jamais installé ni lancé Python. Même pour quelqu’un qui connaît Python, c’est assez pénible
      Il y a aussi des gens qui utilisent Excel sur des appareils iOS et Android. Avec cette approche, eux aussi peuvent utiliser et lire le Python présent dans les feuilles de calcul
    • Il y a aussi Grist. Ce n’est pas un clone d’Excel, mais c’est un tableur/base de données hybride, donc il peut faire une partie de choses similaires, et surtout on peut utiliser Python dans les formules ; si l’on veut l’exécuter localement, il existe aussi une option auto-hébergée

  • En 2005, avec des amis, nous avons créé une société appelée Resolver Systems pour développer Resolver One, un tableur compatible avec Python
    Malheureusement, il n’a pas décollé sur le marché, et nous avons changé de cap pour créer PythonAnywhere, un environnement de codage et d’hébergement en ligne ; celui-là a plutôt bien marché et a été racheté l’an dernier par Anaconda. Et maintenant, la boucle est bouclée
    Pour être clair, l’équipe qui développe cette fonctionnalité chez Anaconda est totalement distincte de l’équipe PythonAnywhere. Si c’avaient été les mêmes personnes, cela aurait fait une parfaite histoire hollywoodienne

    • C’était un bon produit. Je me souviens du pitch, et on s’est croisés plusieurs fois aux rencontres Python finance de Londres. Je me souviens aussi de « Enthought Python Distribution »
      Le problème, c’est que Resolver était basé sur IronPython, donc pas mal de bibliothèques ne fonctionnaient pas correctement
    • J’ai créé ma première application sur PythonAnywhere. Certaines choses y tournent depuis presque dix ans
      J’aimais vraiment pouvoir faire de petites modifications directement dans l’application Web PythonAnywhere, et quand j’ai commencé à utiliser GCP/AWS, cette fonctionnalité m’a beaucoup manqué
    • PythonAnywhere est excellent. Comme pour d’autres, c’est aussi là que j’ai fait mes premiers pas en programmation Web
    • Dès que j’ai entendu cette nouvelle, Resolver Systems m’est immédiatement revenu en tête

  • En voyant la phrase « Les calculs Python s’exécutent dans Microsoft Cloud », un collègue a plaisanté : « On dirait que même Microsoft n’arrive pas à gérer une installation locale de Python sous Windows… »
    Mais il est amusant d’imaginer Microsoft résoudre enfin vraiment le problème de la configuration d’environnements Python locaux, et Excel devenir le gestionnaire de paquets Python standard à l’échelle du système d’exploitation
    $ excelpip install fastapi==9.11.23
    Recherche de la version 11.09.2023 de fastapi…

    • Depuis que j’ai touché à apt sur Debian il y a 20 ans, j’attends que Microsoft résolve la gestion des paquets sous Windows. Ce n’est pas du sarcasme : vu la complexité des produits Microsoft et son obsession de la rétrocompatibilité, l’entreprise me semblait au contraire bien placée pour faire avancer la gestion logicielle
      Je pensais qu’elle allait creuser le problème en profondeur et réinventer un gestionnaire de paquets dépassant ce qui était sorti du monde open source
      À la place, nous avons aujourd’hui Windows Update, Windows Features, Microsoft Store, Software Center et winget. winget est un gestionnaire de paquets pour Windows créé par Microsoft, qui doit être installé depuis un autre gestionnaire de paquets pour Windows créé par Microsoft
    • Ce genre de problème me vient à l’esprit. Microsoft devrait-il figer un ensemble de paquets LTSC ? Comment l’agence $GOV_AGENCY, qui utilise une version d’Excel en retard d’une génération, collaborera-t-elle avec le reste du monde ?

  • LibreOffice aurait dû sentir le vent tourner depuis longtemps. En principe, le scripting Python est possible, mais c’est excessivement fastidieux et brouillon, et il ne semble pas y avoir de feuille de route d’amélioration
    Le même avertissement vaut aussi pour le bureau Linux et ses applications dans leur ensemble. De plus en plus de plateformes propriétaires ajouteront aux applications existantes des extensions de fonctionnalités avancées d’« IA », basées sur le cloud, souvent via des API Python
    Il est dommage que tant de courants du monde open source soient trop siloïsés. Un potentiel supérieur à la somme des parties est gâché

    • Dans bien des cas, ce ne sont pas les fonctions avancées qui retiennent les gens sur Excel et d’autres produits propriétaires, mais des détails qui peuvent sembler insignifiants
      Ce qui me frustre le plus dans le tableur de LibreOffice et dans Apple Numbers, c’est la gestion du copier/coller de sélections non contiguës
      Par exemple, dans des données de 5 lignes sur 3 colonnes, si l’on sélectionne et copie les lignes 1 2 3, 7 8 9, a b c, puis qu’on les colle sous d e f, Excel colle seulement les lignes sélectionnées à la suite. LibreOffice et Numbers conservent aussi les lignes vides intermédiaires
      Je n’ai pas trouvé de réglage pour changer ce comportement. À l’inverse, Excel peut aussi agacer ceux qui veulent préserver les espacements, mais comme je n’ai presque jamais voulu les conserver, LibreOffice et Numbers me gênent
    • LibreOffice intègre le scripting Python presque depuis le début
      Si les gens n’y prêtent pas beaucoup attention, c’est parce que le cas d’usage le plus populaire des suites bureautiques est l’interopérabilité avec les formats de fichiers Microsoft
    • ScriptForge vaut le coup d’œil : https://help.libreoffice.org/latest/en-US/text/sbasic/shared...
      Pour exécuter des scripts dans LibreOffice, l’organiseur de scripts APSO est recommandé : https://extensions.libreoffice.org/en/extensions/show/apso-a...
    • Je vois plutôt l’inverse. Python rend le scripting tellement facile qu’Excel est en train de planter un clou dans son propre cercueil
      À mesure que la génération d’utilisateurs âgés qui n’ont jamais utilisé de langage de programmation vieillit et part à la retraite, ceux qui apprennent à combiner Python avec Excel finiront par préférer Python. Parce qu’il est plus flexible et extensible
      À part pour un usage de feuille de calcul basique, il n’y a aucune raison d’utiliser Excel. Quand quelqu’un demande un tableur, j’en automatise la génération avec Python pour ne plus jamais avoir à le manipuler directement
    • LibreOffice a beaucoup d’autres problèmes à régler d’abord. C’est trop lent

  • Décevant
    « Python dans Excel est actuellement disponible pour les utilisateurs exécutant le canal bêta sous Windows. Cette fonctionnalité est d’abord déployée dans Excel pour Windows à partir de la build 16.0.16818.2000, puis sera proposée sur d’autres plateformes. » [1]
    « Python dans Excel est disponible dans Excel pour Windows. Cette fonctionnalité n’est pas disponible dans Excel pour Mac, Excel pour le web, Excel pour iPad, Excel pour iPhone ni Excel pour Android. Sur les plateformes non prises en charge, les classeurs contenant Python peuvent être consultés, mais une erreur s’affichera si les cellules Python sont recalculées. » [2]
    [1] https://techcommunity.microsoft.com/t5/excel-blog/announcing...
    [2] https://support.microsoft.com/en-us/office/introduction-to-p...

  • « Les calculs Python s’exécutent dans Microsoft Cloud » : non merci

    • Ce point m’a aussi sauté aux yeux. Je me demande pourquoi ils ont choisi ce modèle
    • J’aimerais vraiment une excellente intégration de Python dans une suite de tableur, mais je n’ai même pas l’intention d’essayer celle-ci

  • Attendez. LibreOffice a Python depuis des années, personne ne s’en est soucié, et à la place les gens se plaignaient qu’il fallait une compatibilité VBA à 100 % pour le « vrai travail ». Où sont-ils maintenant ?

    • Ici. Le problème n’est pas seulement la compatibilité VBA à 100 %, c’est aussi de devoir apprendre une API entièrement nouvelle pour créer des tableurs basés sur VBA qui ne fonctionneront pas dans Excel
      Si le VBA de LibreOffice avait été compatible avec le VBA d’Office, il n’y aurait eu aucune raison de garder quelque part un vieux système Windows
      Si nous faisons cela, c’est pour gagner de l’argent, et personne ne veut acheter des tableurs Excel qui ne fonctionnent pas dans Excel
    • Ce n’est pas que je sois contrarié qu’Excel puisse faire plus de choses, mais LibreOffice peut encore être pénible parce qu’il lui manque des fonctions auxquelles on est habitué, ou des fonctions qu’on est obligé d’utiliser
    • Si l’un de mes clients utilisait LibreOffice, je l’utiliserais volontiers. Mais personne ne l’utilise
      Je travaille sous Linux avec LibreOffice Calc, et comme Excel n’a aucun support Linux, j’aimerais qu’il y ait assez de compatibilité pour pouvoir envoyer des fichiers aux clients sans problème, mais on en est encore très loin
    • Si les fonctionnalités sont médiocres, les gens ne les utilisent pas
      Si les gens ignorent qu’elles existent, ils ne les utilisent pas
      S’ils sont habitués à autre chose, ils l’exigent
    • Le problème de LibreOffice, c’est que sa prise en charge de Python n’existait que sur le papier