Dessiner un cuboïde, créer un raccourcisseur d’URL, lire des variables dans un fichier de configuration, implémenter le code de César… Autant de tâches de programmation qui figurent au catalogue de Rosetta Code.

Le projet en réunit plus d’un millier. Il cherche à collecter des solutions dans un maximum de langages. Son dataset a servi de base à une expérimentation dont un des fondateurs de CatchMetrics (optimisation des sites web) a récemment rendu compte. L’objectif était de déterminer quels langages sont frugaux en tokens – et donc susceptibles de moins encombrer la fenêtre de contexte des agents de codage.

Les langages dynamiques (juste) devant les langages fonctionnels

Le travail de comparaison a été confié à Claude Code, à l’appui d’un portage communautaire du tokenizer de GPT-4. L’agent avait, au préalable, sélectionné 19 langages « populaires » et avait récupéré les tâches ayant des solutions dans chacun de ces langages.

L’auteur de l’expérimentation admet les limites et les biais potentiels de son approche, qu’il reconnaît dépourvue de « rigueur scientifique » (pas de communication du prompt, entre autres). Il en souligne toutefois quelques enseignements. Entre autres, la plus grande efficacité des langages dynamiques (Clojure, Julia, Ruby, Perl et Python occupent les 5 premières places). Ne pas avoir à déclarer de types explicites aide, considère-t-il.

L’intéressé s’étonne de l’efficacité de langages fonctionnels comme Haskell et F#. L’un et l’autre consomment à peine plus de tokens que les langages dynamiques. C’est sans doute dû mécanisme d’inférence de types, estime-t-il.

La frugalité des langages orientés tableaux

Ses conclusions ont fait réagir. On lui a notamment rappelé les garanties qu’apportent les annotations de type… et le coût – en efforts comme en tokens – nécessaire pour en apporter de comparables dans les langages à typage dynamique.

On lui a aussi suggéré de tester des langages orientés tableaux. Ce qu’il a fait, avec APL et J.
APL se classe au 4^e rang, consommant 110 tokens en moyenne. Sa syntaxe concise est un plus. Au contraire de son jeu de caractères, riche en glyphes (⍳, ⍴, ⌽…) auxquels le tokenizer est mal adapté.
Limité à de l’ASCII, J se révèle plus frugal, descendant à 70 tokens de moyenne.

L’expérience a ses limites en ce qu’elle se focalise sur de petites tâches. De même, le tokenizer est fixe, alors qu’on pourrait le réentraîner pour mieux gérer le code. L’auteur ne dit pas ailleurs pas si son comparatif a pris en compte les éventuelles erreurs à l’exécution et les tokens qu’elles ont consommés. Il n’aborde pas non plus les spécificités syntaxiques des langages. Par exemple, le fait que certains intègrent du code de formatage de texte dans des chaînes littérales comptées comme des tokens, tandis que d’autres ont un usage important des espaces – on peut citer les indentations de blocs dans Python – quant à eux possiblement pas comptés comme des tokens.

Illustration générée par IA

The post Codage IA : les langages les plus frugaux en tokens appeared first on Silicon.fr.

À l’heure où les infrastructures deviennent de plus en plus éphémères et complexes, les méthodes de monitoring traditionnelles atteignent leurs limites. De l’émergence de l’eBPF, qui permet une visibilité profonde et sans agent au cœur du noyau Linux, à l’adaptation de l’observabilité pour le Serverless, les entreprises basculent vers un modèle « as-Code ».

Cette convergence technologique ne se contente plus de surveiller la disponibilité des services ; elle intègre la donnée de performance dès la conception logicielle (Observability-as-Code), transformant l’infrastructure invisible en un système transparent, automatisé et hautement résilient.

eBPF : Le « super-pouvoir » du noyau

Cet article sur l’eBPF (Extended Berkeley Packet Filter) explique comment cette technologie révolutionne le DevOps. Traditionnellement, pour surveiller un système, il fallait modifier le code de l’application ou charger des modules noyau risqués.

> Le concept : eBPF permet d’exécuter des programmes directement dans le noyau Linux de manière sécurisée, sans changer une seule ligne de code applicatif.

> L’avantage DevOps : Une visibilité totale sur le réseau, la sécurité et les performances avec un impact quasi nul sur les ressources. C’est la fin des agents « lourds » qui ralentissent les serveurs.

A lire : https://www.silicon.fr/cloud-1370/ebpf-devops-225348

Le défi de l’observabilité Serverless

Cet article traite de la complexité du Serverless (comme AWS Lambda). Puisque vous ne gérez plus le serveur, vous perdez l’accès aux métriques matérielles classiques.

> Le problème : Les fonctions sont éphémères (elles apparaissent et disparaissent en quelques millisecondes). Les outils de monitoring classiques sont souvent trop lents pour les capturer.

> La solution : Le traçage distribué. L’accent est mis sur le suivi de la requête à travers tous les services plutôt que sur la santé d’un serveur spécifique.

A lire : https://www.silicon.fr/cloud-1370/observabilite-serverless-225361

L’Observability-as-Code (OaC)

Cet article prône l’intégration de l’observabilité directement dans le cycle de développement, au même titre que l’Infrastructure-as-Code (Terraform, CloudFormation).

> L’idée : Au lieu de configurer manuellement des alertes et des tableaux de bord après le déploiement, vous les définissez dans votre code YAML ou JSON.

> L’objectif : Garantir que chaque nouveau microservice est « né » avec ses propres outils de mesure, évitant ainsi les angles morts lors des mises en production rapides.

A lire :  https://www.silicon.fr/cloud-1370/observability-as-code-225520

The post Observabilité native : la nouvelle frontière du Cloud et du DevOps appeared first on Silicon.fr.

Peur de la perte d’historique et du conflit de versions, risque de rupture de la chaîne si quelqu’un télécharge… Autant d’éléments qui peuvent expliquer le recul de la collaboration sur fichiers.

L’OICN (Observatoire de l’infobésité et de la collaboration numérique) contextualise ainsi ce phénomène qu’il a lui-même constaté entre les deux dernières itérations de son référentiel annuel.

Le collectif est né en 2023, sous l’impulsion de Mailoop et de Mazars. Objectif : étudier les impacts sociaux, organisationnels et environnementaux de la surcharge informationnelle. Il réunit aujourd’hui des membres d’organisations comme le Groupe ADP, Dalkia, La Poste, Orange, la CNAF, la Région Normandie et la Ville de Paris.

Beaucoup de conservation, peu de collaboration

L’OICN a publié jusque-là trois éditions de son référentiel, centré sur les usages numériques en milieu professionnel. La dernière se fonde sur l’analyse de métadonnées de 190 millions d’e-mails et de 3 millions de réunions. Elle englobe 17 000 personnes (78 % de collaborateurs, 16 % de managers, 6 % de dirigeants, avec autant d’organisations du public que du privé).

La collaboration sur fichiers reste assez occasionnelle. Sur l’ensemble de l’échantillon, 23 % n’y ont pas recours. Ils ne sont que 1 % à s’y livrer au moins une fois par semaine. Pour la plupart (58 %), c’est moins d’un fois par mois.

Pour autant, la tendance est à converser de nombreux fichiers inutiles : 46 % de ceux stockés n’ont pas été ouverts au cours des 6 derniers mois. L’OICN l’explique, entre autres, par :

• Illusion du stockage illimité et infini
• Messagerie électronique vue comme une « mémoire professionnelle »
• Difficulté à considérer l’information comme périssable

Un collaborateur conserve en moyenne 13 138 e-mails et 2308 fichiers dans le cloud ; un manager, 26 728 e-mails et 5338 fichiers ; un dirigeant, 44 579 e-mails et 13 028 fichiers.

Un usage anecdotique des groupes collaboratifs

L’usage des groupes collaboratifs – type équipes Teams – est encore plus occasionnel. 68 % des collaborateurs ne les utilisent pas, ainsi que 57 % des dirigeants et 52 % des managers. En moyenne, on y poste 2,4 messages par semaine (2,5 pour les collaborateurs, 2,4 pour les managers, 2,1 pour les dirigeants). La quasi-totalité (96 %) sont postés par 10 % des utilisateurs. L’OICN y voit le reflet d’une difficulté à partager de l’information horizontalement sans en conserver le contrôle.

Mis dans la balance avec les e-mails et le chat, ces groupes concentrent une part négligeable du volume de messages envoyés dans les organisations qui ont des outils collaboratifs. En l’occurrence, 0,2 % chez les collaborateurs, 0,1 % chez les managers et moins chez les dirigeants.

Le chat concentre près des trois quarts des messages envoyés (74 %). En un an, le volume a presque doublé (+ 90 %), contrastant avec le recul de l’e-mail (- 57 % de messages).

Le taux d’usage hebdomadaire du chat atteint 71% chez les managers, contre 65 % chez les collaborateurs et 55 % chez les dirigeants. Pour ces derniers, la communication passe toutefois encore majoritairement par l’e-mail (84 %). Même constat chez les managers (52 %), mais pas chez les collaborateurs (38 %).

Réunions : les « tunnels », pas si rares

D’une année à l’autre, le nombre d’e-mails envoyés a diminué. Tandis que le nombre de destinataires et d’e-mails reçus a augmenté. Le développement du distanciel engendre un besoin de traces écrites, déclare l’OICN à ce sujet.

La majorité des dirigeants (72 %) ne passent pas une semaine sans envoyer d’e-mails. Il en va de même pour 52 % des managers et 24 % des collaborateurs.
La part des e-mails envoyés hors de la plage 9 heures – 18 heures va de 14 % pour les collaborateurs à 27 % chez les dirigeants.

Les « tunnels de réunions » (plus de 6 heures dans une journée) arrivent en moyenne 9 fois par an pour les collaborateurs. 20 fois pour les managers, 41 fois pour les dirigeants. À ces niveaux hiérarchiques respectifs, la participation à des réunions consomme environ 6 heures, 12 h 30 et 18 h 30.

Illustration générée par IA

The post Digital workplace : le cloud, lieu de conservation plus que de collaboration appeared first on Silicon.fr.