Plusieurs médias américains évoquent que Google fait revenir certains salariés au bureau au moins 3 jours par semaine. Si l'employé ne veut pas, ou ne le fait pas, Google pourrait le licencier. Selon CNBC, les salariés des services techniques devraient choisir entre un travail hybride (télétravail et présence sur site) ou accepter une indemnité de départ volontaire. Toujours selon le media américain, les salariés habitant à plus de 80 km auraient une aide financière pour se rapprocher.

En février dernier, un mémo interne mobilisait les équipes de Gemini à retourner dans les bureaux à plein temps pour mieux faire interagir les équipes.  

Aux Etats-Unis, les sociétés technologiques réduisent le télétravail ou le supprime totalement. La tendance est identique en France. 

Bootstrap est disponible en version 5.3.6. Cette mise à jour corrige des bugs. La 5.3.6 migre la documentation sur Astro et retire Hugo. Le projet met à jour la documentation sur les derniers éléments JavaScript et retire Sass. Le principal focus reste la correction de bugs. 

Note de version : https://github.com/twbs/bootstrap/releases/tag/v5.3.6

Game Bub a l'ambition de créer une Game Boy moderne, open source et basée sur un processeur FPGA. Cette console supportera les jeux Game Boy, Color et Advance. Elle supportera même le multi-joueur avec le câble dédié !

Pour réussir le projet, le coeur est un FPGA de Xilinx. C'est ce composant qui va assurer l'émulation Game Boy et être le plus possible de l'original. Pour la partie interface, gestion des I/O, la console embarquera un ESP32-S3. Ce micro-contrôleur gérera aussi le chargement des ROM depuis la carte SD. 

Quelques caractéristiques :

- ports USB et HDMI (pour un écran externe)

- Ecran LCD IPS 480x320

- WiFi et Bluetooth LE

- lecteur microSD

- un dock dédié sera proposé en option

- 32 Mo de RAM

Le projet est totalement open source : https://github.com/elipsitz/gamebub

La campagne de financement n'est pas encore lancée : https://www.crowdsupply.com/second-bedroom/game-bub

C'est officiel, 13 ans après avoir lancé un audio guide basé sur la Nintendo 3DS, le musée du Louvre a annoncé qu'à partir de septembre 2025, ce matériel ne sera plus disponible au musée. Le Louvre et Nintendo avaient travaillé ensemble pour concevoir un guide interactif utilisant la géolocalisation et une application développée par Nintendo avec modélisation 3D des oeuvres et plus de 30h de commentaires. 

Le projet avait exploité au mieux les possibilités de la console. 

Le musée a annoncé qu'un nouveau système sera déployé sans donner de détails sur le matériel et l'application.

Programmez! vous propose un double meetup spécial IA

Session 1 : L'IA pour la musique et les musiciens
Comment l'IA bouscule doucement, mais surement le milieu musical ? Où en sont les algorithmes ? Qu'est-ce que l'IA permet de faire aujourd'hui ? Quelles sont les limitations et les projections ? Comment l'IA et les algorithmes classiques peuvent co-exister pour donner des résultats optimums ? Par Benoît, musicien diplômé et informaticien, vous fera un tour d'horizon des outils et des possibilités actuelles et futures

Session 2 : l'IA Act concerne aussi les développeurs
La session démarre par un rapide résumé de l'histoire de l'IA puis nous parlerons des principaux éléments de l'IA Act et ses impacts : technique, juridique et financier. Par Christophe Perrot (PMO freelance, membre OpenLLM)

Quand : 13 mai, début des sessions à 18h30. Accueil dès 18h / 18h15

Où : 42 avenue de la porte de Clichy, Paris, dans les locaux de OVHcloud

Détails et inscription : https://www.meetup.com/meetup-programmez/events/305605853/?slug=meetup-programmez&eventId=305605853

OVHcloud héberge les meetups Programmez! du 1er semestre 2025

Les écrans e-ink sont surtout utilisés pour les étiquettes, les affichages plutôt statiques et les liseuses. Pour un usage plus intensive, comme un écran, c'est plus rare. C'est le défi de Boox en lançant le Mira Pro. Il supporte nativement Linux, macOS et Windows. Il se décline en e-ink monochrome et en couleur. Le design est très réussi et les détails semblent bien pensés. 

Il autorise une résolution de 3 200 x 1 800 en 144 ppi, en 16:9. La version couleur se limite à 4 096 couleurs. La connectique est classique : HDMI, mini HDMI, USB C, Display Port. Attention, il n'est pas question d'avoir un usage intensif par exemple la production vidéo ou le gaming, ni jouer des vidéos. Le rafraichissement est trop lent pour tenir la comparaison avec un OLED ou un simple LCD et les limitations dans l'affichage des couleurs limitent de facto son usage. Il permet tout de même d'affirmer la chaleur de la couleur.

Des retours d'utilisateurs mentionnent la présence d'images fantômes, vous pourrez alors forcer le rafraichissement. 

La communauté Python s'active sur les prochaines versions du langage. 

Version 3.14

Actuellement, l'alpha 7 a été distribuée début avril. La phase bêta est attendue pour mai. La bêta fixe les nouveautés et les évolutions du langage. La version finale est attendue pour le 7 octobre

Version 3.15

La prochaine version, la 3.15, a été annoncée fin avril dernier. Le développement débutera courant mai avec la stabilité de la 3.14. La phase alpha s'ouvrira mi-octobre. Les bêtas sont planifiées pour mai, juil et juillet 2026. La version finale devrait sortir début octobre 2026.

JetBrains travaille sur la prochaine version de CLion. Trois fonctionnalités majeures sont évoquées :

- le moteur Nova pour améliorer son fonctionnement et fixer les bugs

- nouvelles fonctions pour le développement embarqué

- support de Junie (agent IA)

Parmi les améliorations annoncées, nous trouvons un meilleur assistant pour le développement distant, meilleure analyse des erreurs de compilation, nouveautés sur les ESP32 et l'intégration FreeRTOS.

CLion est un environnement de développement C et C++ sur Linux, macOS et Windows. 

La version 2025.2 est prévue pour juillet. 

Saviez-vous qu'un explorateur de fichiers Linux était dans Visual Studio ? Il faut utiliser le remote file explorer de Visual Studio pour se connecter à un environnement Linux distant. Idéal pour faire du développement Linux distant. 

Une vidéo de Scott Hanselman résume bien les possibilités !

Aussi improbable que réelle, une mésaventure involotaire vécue par l'équipe de Kali Linux a gêné les utilisateurs ! Impossible de faire un apt update à cause de l'absence des signatures automatiques pour authentifier et autoriser la mise à jour depuis les référentiels de dépôts. 

L'équipe a été obligée de recréer une nouvelle clé de signature pour les accès aux dépôts Kali. Il faut donc la récupérer et l'installer manuellement :

(kali㉿kali)-[~]

└─$ sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg

"Nous avons perdu l'accès à la clé de signature du dépôt ; nous avons donc dû en créer une nouvelle. Parallèlement, nous avons gelé le dépôt (vous avez peut-être remarqué qu'il n'y a pas eu de mise à jour depuis vendredi 18), donc personne n'a été impacté pour l'instant. Nous allons toutefois dégeler le dépôt cette semaine, et il est désormais signé avec la nouvelle clé." explique Kali Linux. 

Kali explique que la clé et les dépôts n'ont pas été compromis, c'est simplement une erreur qui a mené à la perte de la clé. Cela rappelle une mésaventure sur une clé PGP en 2018 qui avait expiré accidentellement... 

L'OWASP propose un top 10 des risques et vulnérabilités sur les LLM et les genIA en général. L'OWASP confirme que l'IA est loin d'être sécurisée, au contraire, les risques de sécurité se multiplient si l'implémentation est mal faite ou l'usage mal cadré. 

1 - injection : le prompt injection est un classique. Un prompt altère le fonctionnement prévu de la genIA et/ du LLM. Et peu à peu on influence son fonctionnement et on amène à générer des données sensibles ou des exemples d'attaque ou des réponses non prévues. Voir : jailbreaking LLM

2 - des données sensibles sont accessibles : trop d'entreprises laissent des données sensibles / privées sur les LLM. Ces données peuvent être accessibles. Il ne faut pas autoriser les LLM / genIA à accéder à ces données sauf dans un cadre strictement interne et déconnecté de l'extérieur

3 - les chaînes LLM constituent un risque et une surface d'attaque potentielle. Risque de corrompre les modèles ou les données, utiliser des API, des services non sécurisés

4 - données et modèles empoisonnés : cela signifie que les données ne sont pas qualifiés ou corrompues. Si ces données ne sont pas bonnes, le LLM sera biaisé et générera de fausses informations et de mauvaises réponses = déviance du modèle. Il faut vérifier l'origine des données et la conformité de celles-ci avec ce que l'on veut générer. Il faut aussi que le LLM soit bien défini et cadré.

5 - La gestion incorrecte des sorties fait spécifiquement référence à une validation et une gestion insuffisantes des sorties générées par le LLM. Et cela peut se propager et corrompre d'autres systèmes

6 - Trop d'agent IA peut nuire à la sécurité et au bon comportement. Avec les agents on peut perdre le contrôle de ce qu'il se passe et favoriser l'hallunication. La qualité médiocre d'un LLM est exploitée. L'agent ou la genIA ne fait pas la différence entre un bon LLM et un mauvais LLM

7 - Fuite au niveau du prompt : il ne faut pas que des identifications, des secrets ou données sensibles se retrouvent dans les réponses du prompt. Il doit "comprendre" ce qui peut être généré ou non. 

8 - Une mauvaise intégration peut être une source de vulnérabilités. Cela peut être accentué en utilisant du RAG.

9 - désinformation : finalement c'est une combinaison des précédents points

10 - consommation illimitée : on n'y pense pas forcément car un déni de services peut impacter un service IA, un genIA en le saturant de prompts qui va alors peser sur l'infrastructure. Cela peut être possible avec des prompts nombreux et longs, des requêtes envoyées en grande quantité dans un délai très court, des API mal limitées pouvant faire exploser les ressources, etc. 

Cette chronique a été générée par ChatGPT :-)

En 2025, le développement logiciel vit une accélération sans précédent de ses paradigmes. Porté par l’IA générative, le cloud natif et une complexification croissante des architectures distribuées, le métier de développeur exige une montée en compétence continue et une compréhension fine des systèmes. Tour d’horizon des tendances techniques qui façonnent l’ingénierie logicielle moderne.

1. IA générative : du pair programming à l’auto-complétion contextuelle

L’intégration de LLMs (Large Language Models) dans les IDE n’est plus anecdotique. GitHub Copilot, CodiumAI, ou les extensions JetBrains avec modèles embarqués permettent aujourd’hui de générer du code à partir de prompts en langage naturel, de rédiger des tests unitaires avec couverture contextuelle, voire de refactoriser en continu. L’usage devient productif dès lors que le développeur garde une posture critique. L’enjeu n’est pas la génération, mais la vérification : typage strict, tests automatisés, et revue de code deviennent des garde-fous indispensables.

2. Évolution des architectures : microservices, DDD et event-driven

Les monolithes cèdent définitivement la place aux architectures distribuées. Les microservices, souvent couplés à une approche Domain-Driven Design (DDD), permettent une granularité fonctionnelle mieux alignée sur les besoins métier. La montée des architectures event-driven avec Kafka, NATS ou RabbitMQ transforme les systèmes en ensembles loosely coupled mais fortement cohérents. Les problématiques de traçabilité (observabilité distribuée), de transactions (sagas, CQRS) et de résilience (circuit breakers, retries) sont désormais au cœur du code métier.

3. Cloud natif, Infrastructure-as-Code et GitOps

Le « cloud native » n’est plus un luxe mais un prérequis. Kubernetes s’est imposé comme l’orchestrateur de référence, avec Helm, ArgoCD et Terraform comme standards pour le déploiement. Les pratiques GitOps permettent de versionner non seulement le code applicatif, mais aussi l’état de l’infrastructure. Cela implique une culture du "code as policy" : les environnements sont reproduits de manière déclarative, et les rollbacks sont aussi simples qu’un git revert. Le développeur devient ainsi un acteur direct de l'infrastructure.

4. DevSecOps, CI/CD et qualité continue

L'automatisation est totale : chaque commit déclenche une pipeline CI, avec build, tests, analyse statique (SonarQube, Semgrep), et éventuellement un scan de vulnérabilités (Snyk, Trivy). Le déploiement continu (CD) via des stratégies comme blue/green ou canary release devient la norme, soutenu par des outils comme FluxCD ou Spinnaker. La sécurité (DevSecOps) s’intègre dès le début : secrets chiffrés dans Vault, politiques réseau via OPA/Gatekeeper, et contrôle d’accès fin (RBAC) sur les clusters.

5. Sobriété et performance : retour à l’essentiel

Le coût environnemental et économique du cloud pousse à une optimisation plus fine : choix de langages plus performants (Rust, Go), réduction des dépendances, optimisation du cold start en serverless, et profilage mémoire/CPU dès le développement. Le GreenOps complète le FinOps dans les équipes techniques, avec des métriques d’empreinte carbone intégrées aux dashboards.

Conclusion : ingénieur full-stack ou full-cycle ?

Le développeur de 2025 n’est plus seulement un producteur de fonctionnalités, mais un artisan de la résilience, de la scalabilité et de la sécurité. La frontière entre dev, ops et security s’estompe, au profit d’équipes autonomes, outillées, et responsables de bout en bout. La dette technique n’est plus tolérée ; la qualité devient un impératif. Plus que jamais, coder, c’est concevoir des systèmes vivants, robustes et intelligents.

14 mois après avoir tourné le dos à l'open source en changer de licence, Redis redevient Open Source. Il faut dire que cette décision avait provoqué la colère de la communauté et des forks étaient nés. Redis change donc d'avis en prenant une licence AGPLv3. 

Pour expliquer ce revirement, Redit explique "...nous avons décidé, en mars 2024, de migrer Redis vers la licence SSPL. Notre objectif a été atteint (AWS et Google maintiennent désormais leur propre fork), mais ce changement a fragilisé nos relations avec la communauté Redis. SSPL n'est pas véritablement open source, car l'Open Source Initiative a précisé qu'elle ne remplissait pas les conditions requises pour être une licence approuvée par l'OSI." Mea culpa mais pas trop.

Ensuite il y a eu des changements dans l'équipe à l'automne 2024 pour préparer la version 8. Et c'est là que le changement de licence s'est imposée : AGPL. Synk présente cette licence ainsi : "dans le cadre de la licence GPLv3, la Free Software Foundation (FSF) a fourni deux types de licences supplémentaires : la licence publique générale limitée (LGPLv3) et la licence publique générale Affero (AGPLv3). La version AGPL de la licence publique générale vise à appliquer des droits de copyleft complets à tous les logiciels qui l’utilisent. Avec la licence AGPL, les équipes des logiciels peuvent s’assurer que toutes les modifications apportées à la base de code sont mises à la disposition du public, même pour les applications côté serveur."

Ainsi si un éditeur, un développeur, un fournisseur cloud ajoute des fonctionnalités à Redis, il devrait ouvrir le code. S'il ne souhaite pas le faire, il pourrait prendre la licence commerciale. 

Annonce : https://redis.io/blog/agplv3/

Drupal se prépare à ouvrir les tests de la 11.2 avec l'alpha 1 disponible le 7 mai prochain. Il s'agit d'une version mineure. La priorité est donnée à la correction de bugs. Les développeurs peuvent déjà testés mais pas en production.

Les points déjà connus :

- patch de sécurité

- bug fix des versions précédentes

- les évolutions et nouveautés seront fixées dans la RC prévue sans la semaine du 2 juin

Les patchs de sécurité des versions 10.3.x, 11.0.x et 10.4.x et 11.1.x seront assurés jusqu'au 18 juin et 10 décembre.

Annonce : https://www.drupal.org/about/core/blog/drupal-112-alpha-phase-begins-may-7

Lors d'un échange avec Mark Zuckerberg à conférence LlamaCon, Satya Nadella a évoqué l'usage de l'IA pour créer le code chez Microsoft : 20 à 30 % des codes utilisés en interne par l'éditeur sont générés par des IA et que des projets sont sans doute totalement générés, même si officiellement aucune mesure n'est mise à jour pour estimer cette génération. Cette génération concerne tous langages. 

Ce n'est pas une surprise, Microsoft évoque régulièrement le rôle de la GenIA dans les nouveaux codes. Google évoquait il y a quelques mois que 25 % des nouveaux codes sont générés par une IA. Shopify affirmait mettre en avant la GenIA pour coder et qu'il fallait prouver l'apport réel d'un nouveau développeur dans les équipes.

Il y a quelques semaines, Kevin Scott, CTO de Microsoft, allait bien plus loin en affirmant que 95 % du code seront générés par des IA d'ici 2030. 

A croire qu'il y a une course à celui qui générera le plus de codes par l'IA.

L'éditeur Armis lance Armis Vulnerability Intelligence. Cette nouvelle base de données a l'ambition d'agréger les vulnérabilités exploitées, les menaces et des compléments d'informations liées à ces vulnérabilités. Cette base est communautaire et gratuite. 

Le projet est alimenté par les données d'Armis Labs et des diverses solutions de l'éditeur. "La base de données Armis Vulnerability Intelligence est une ressource clé, pensée par la communauté pour la communauté de la cybersécurité. Elle transforme les données de vulnérabilités en informations concrètes, permettant aux entreprises de mieux se protéger contre les cybermenaces grâce à une adaptation plus rapide et des prises de décisions éclairées." explique Nadir Izrael, CTO et cofondateur d'Armis.

Pour Armis, il s'agit d'aider les entreprises à réagir plus vite et si possible avant une attaque : 58 % des grandes entreprises réagissent après l'attaque et les conséquences de celle-çi. Par ailleurs, près d'un quart (22 %) des décideurs informatiques reconnaissent l'absence d’une évaluation continue des vulnérabilités comme une faiblesse dans leurs dispositifs de sécurité, et nombreux sont ceux qui s’appuient encore sur des feuilles Excel pour suivre les vulnérabilités et les résultats de sécurité. Ces lacunes doivent ainsi être comblées en amont pour éviter les impacts négatifs.

Site : https://cve.armis.com/

Ce n'est pas une surprise : le chip act européen connaît une réalisation partielle et l'objectif de 20 % du marché mondial ne sera pas atteint. «L’Europe doit d’urgence confronter sa stratégie pour le secteur des microprocesseurs à la réalité du terrain», a déclaré Annemie Turtelboom, la Membre de la Cour responsable de l’audit. «Nous avons affaire ici à une industrie en rapide évolution, marquée par une concurrence féroce sur le plan géopolitique. Et au rythme actuel, nous ne pourrons certainement pas concrétiser nos ambitions. L’objectif de 20 % relève du vœu pieux: pour l’atteindre, il nous faudrait multiplier quasiment par quatre notre capacité de production dans les cinq prochaines années. Autant le dire, nous sommes à la traîne. L’Europe doit pouvoir rivaliser, mais pour ce faire, la Commission européenne doit d’abord revoir sa stratégie à long terme pour mieux coller à la réalité du marché.»

L'ambition de peser 20 % du marché des processeurs d'ici 2030 était dès le départ une illusion. L'Europe part de très loin et surtout, elle manque de fondeurs capables de rivaliser avec Intel, TSMC, Samsung, etc. Nous avons des fabricants actifs dans certains secteurs industriels comme l'automobile mais pas sur les CPU et GPU. 

Nous avions pointé du doigt le manque d'investissement : à peine 5 milliards € sur les 86 milliards qu'ils auraient fallu investir en Europe. Bref, l'Europe mobilsait trop peu pour espérer peser. Le chip act misait donc les Etats et les industrueils pour investir le reste. La cour des comptes européenne pointe la cruelle réalité : sur la même période, les géants du semi-conducteur annonçaient des investissements colossaux : 405 milliards € !

Une forme de naïveté apparaît dans le rapport de la cour des comptes : "Cela étant, comme les auditeurs le soulignent, la Commission européenne n’a pas de mandat pour coordonner les investissements nationaux et ainsi les aligner sur les objectifs de l’action européenne. Par ailleurs, le Chips Act manque de clarté dans ses objectifs et son suivi, de sorte qu’il est difficile de savoir s’il tient dûment compte de la demande actuelle de microprocesseurs conventionnels dans l’industrie."

Et c'est là un des problèmes. L'Europe brandit une forte ambition mais laisse la réalisation aux Etats et aux industriels sans vouloir peser réellement sur une stratégie globale pour développer une vraie industrie du processeur. 

Outre ce problème, le sous-investissement et le manque d'actions de la plupart des Etats, la cour des comptes pointe plusieurs problèmes (largement sous-estimés ou tout simplement "oubliés") :

- l'accès aux terres rares

- la situation géopolitique et les tensions commerciales (ex. : les restrictions de vente imposées par les Etats-Unis)

- le coût énergétique

- le manque de main d'oeuvre (hautement) qualifié

- le manque de leaders de taille internationale

"Tout abandon, retard ou échec d’un seul projet peut dès lors avoir un impact considérable sur l’ensemble du secteur." complète le rapport.

En 2030, la cour des comptes estime que l'Europe devrait peser 11,7 % du marché mondial, contre 9,8 % en 2022. Le gain est donc très limité.

Rappelons qu'une usine de semi-conducteurs de dernière génération coûte jusqu'à 5 milliards $. ASML, fleuron de l'industrie européenne, est incontournable pour créer les matrices des semi-conducteurs de dernière génération. Une seule machine ASML coûte environ 350 millions $ (prix catalogue, sans la maintenance et les évolutions). L'Europe manque d'usines pouvant rivaliser avec les fondeurs mondiaux.

Le e-ink, ou e-paper, n'est pas une technologie nouvelle. Nous avons déjà eu l'occasion de publier des articles sur le sujet dans le magazine. Le e-paper commence à se diffuser par des procédés de fabrication fiables et plus faciles d'accès.

Le e-paper consomme peu et reste dans un état figé ce qui lui permet de garder le dernier affichage même quand il n'est pas alimenté. Ces caractéristiques permettent de l'utiliser dans des objets contraints et surtout les solutions flexibles économisent de la place.

Cette approche autorise des formats de la taille d'un ongle à une affichage beaucoup plus grand comme de la signalétique. Ynvisible, un fabricant européen, cible le commerce, la santé, l'industrie, la logistique. Dans les magasins, ces solutions remplacent les étiquettes imprimées ou même les blocs de prix en rayon car ils utilisent souvent des écrans e-ink rigidesencombrants.

Ces e-paper flexibles sont imprimés par couche sur des "rotatives" capables d'imprimer des centaines de displays à la fois. Ce e-paper est un empilement de couches pour l'affichage et les parties conductrices pour assurer son contrôle. Autres avantages : on peut l'adapter à des formes rondes, il ne casse pas et il peut prendre la forme que l'on veut, et adapter le design selon l'usage. Contrairement au e-ink classique, l'affichage n'est pas stable dans le temps. Il est résilient jusqu'à 15 minutes.

Ynvisible précise que son e-paper n'est pas un e-ink "standard" même si les principes restent identiques. Le constructeur utilise des matériaux électrochromes et s'appuie sur les segments d'affichage et non sur des pixels comme le e-ink classique (basé sur l'électrophorétique). Le e-paper électrochrome utilise le champ électrique pour modifier l'apparence, l'opacité, etc. Quand un courant passe, une réaction chimique se fait et altère l'apparence. Typiquement, un voltage de 1,5 volt suffit. Plus les segments sont grands, plus le rafraîchissement est long.

Le kit d'Ynvisible permet de démarrer en douceur avec cette technique. Il comprend plusieurs e-papers et 2 cartes dont un contrôleur que l'on relie facilement à un ESP ou un Arduino. Il fonctionne en I2C. Une librairie Arduino est disponible.

Site : https://www.ynvisible.com/

Pour construire des applications Python avec des interfaces graphiques, il existe plusieurs solutions dont le framework multiplateforme Kivy. Il utilise des widgets pour coder des apps UI complexes. On peut utiliser de nombreux objets : textes, listes, fenêtres, menus, onglets, radians, etc. Il fonctionne sur Linux, macOS, BSD, Windows, iOS, Android, etc. Pour faciliter la manipulation des éléments, le framework utilise un langage spécifique pour séparer la logique applicative et l'interface. 

Kivy définit donc une librairie de widgets, chaque widget est vu comme une classe Python que l'on implémente, par exemple :

class ButtonApp -> pour un bouton

class SpinnerApp -> pour un menu type spinner

Comme toujours, il faut importer dans son code Python, le module : import kivy. Chaque widget est importé avec from kivy.uix.[nom du widget]

La version 2.3.1 est la dernière disponible. Elle fixe de nombreux bugs et le framework supporte les dernières versions de Python 3.x. Elle retire le support de Windows 32 bits et de Python 3.7. Il faut minimum Python 3.8. 

A découvrir :https://kivy.org/

Dans Visual Studio, et tout autre environnement de développement, un problème récurrent existe : l'encodage des fichiers en environnements multiplateformes. Un mauvais encodage peut corrompre un fichier ou gêner son utilisateur quand on change de plateforme matérielle ou de système ou que l'on charge des fichiers d'un autre environnement.

Résultat :

- on perturbe le flux de développement et des équipes

- perte de temps pour résoudre les contrôles

Il n'y a qu'à ouvrir des fichiers .txt ou des fichiers avec des encodages que vous n'utilisez pas, pour voir les problèmes. Cette option est accessible dans : Tools > Options > Environment > Documents

Pour éviter ce problème, Visual Studio introduit une nouvelle fonction : Default File Encoding. Les fichiers seront sauvegardés avec l'encodage indiqué. De facto, les problèmes seront minimisés. "Les développeurs travaillent souvent sur des projets sur différentes plateformes, chacune nécessitant un encodage de fichier spécifique. Une mauvaise gestion de l'encodage peut entraîner divers problèmes, allant de fichiers corrompus à du texte illisible. L'option Encodage de fichier par défaut permet de résoudre ce problème en vous permettant de définir un encodage par défaut, garantissant ainsi la cohérence et réduisant les risques de problèmes d'affichage des caractères ou de corruption des données." explique l'équipe Visual Studio. 

Si la sauvegarde ne peut se faire avec l'encodage par défaut, par exemple quand on veut sauvegarde un fichier avec des éléments Unicode vers ASCII, une alerte est affichée.

Pour les accessoires et matériels, Amazon utilise  Android. Fire OS s'appuie sur le système de Google. Mais les choses seraient sur le point de changer. L'objectif est clair : retirer Android AOSP. Le nouveau système est appelé Vega OS, un projet interne. L'OS est toujours basé sur Linux mais totalement adapté aux besoins des matériels. Avec Vega OS, Amazon veut mieux intégrer système et matériel et maîtriser de bout en boût l'expérience, les fonctionnalités et les optimisations. 

Au moins 3 matériels fonctionnent déjà sous Vega OS : la gamme Echo. Dans les mises à jour, deux OS sont mentionnés : Fire OS et Echo Ship 1.x. Amazon se montre très discret sur cet OS. Et la migration se fait au fur et à mesure. Mais visiblement, l'OS est plus complexe à intégrer dans les Fire Stick par exemple. 

Pour les développeurs, un SDK sera disponible. Il est connu sous le nom de code Kepler. Des recrutements sont / étaient ouverts pour renforcer l'équipe Kepler. 

Attendons de voir quand et comment Amazon libérera le SDK. 

Silkhom vient de publier son baromètre des salaires 2025. Cette étude s'appuie sur les placements de consultants dans toute la France. Ces données reposent sur 20 000 candidats se répartissant entre Paris, les grandes villes et les régions. 

Les postes de direction

Peu de variation des salaires pour les directeurs techniques / CTO, tech lead et les responsables R&D. Le CTO connaît un croissance de 3,6 % en moyenne (77 000 € bruts / an). Pour les RSSI, responsable infrastructure, pas de changements. Comme toujours, il y a un écart entre Paris, les grandes villes et les régions même si les écarts se réduisent. La différence se fait nettement sur les profils avec +5 ans d'expérience. Nous trouvons ce écart sur l'ensemble des postes. En constate que le tech lead a un salaire plus homogène : 55 à 80 000 € en profil senior. 

Développeurs : beaucoup de baisses !

Ce n'est pas une surprise : l'étude indique des baisses du salaire moyen sur de nombreux profils de développeurs allant de - 0,3 à -3,6 %. Rares sont les profils qui connaissent un petit mieux, entre 0,1 et 0,9 %. Cela correspond bien aux tassements des recrutements et du ralentissement des recrutements de certaines entreprises.

Le salaire moyen va de 45,5 à 57,5 k€. Le profil Go et fullstack JS sont les plus chers (57,5 k€). Dans le détail, la baisse ne connaisse pas tous les profils. Par exemple, un dév Java junior connait une baisse de 1,2 %, le senior de 3,6 %. Les régions hors grandes villes semblent épargnées selon Silkhom. Même remarque pour les développeurs Python, , .Net. Ce dernier subit une décote dans les grandes villes. Le développeur Windev / Webdev est plutôt stable, même remarque pour les profils Cobol exceptés sur Paris. 

Pour le développeur PHP, les grandes villes semblent plus dynamiques que Paris. 

Sur la partie développement mobile, là encore, une légère croissance des salaires (maximum 1,3 % en moyenne). Les développement mobile multiplateforme peuvent espérer une petite amélioration sur Paris.

Quelques profils en forte hausse

D'autres profils, hors développement, connaissent des hausses souvent fortes (13-14 %) : compétences DevSecOps, chef de projet infrastructure. L'ingénieur sécurité connaît une hausse de salaire à cause du marché tendu, +7 % en moyenne.  Même pour les profils IA et data, la tendance n'est pas forcément aux hausses de salaires. Le monde l'embarqué s'en sort mieux mais ce sont des domaines très spécifiques. 

GCC 15.1 est disponible depuis quelques jours. La v15 avait introduit de nombreuses évolutions : compilateur frontend Cobol, amélioration sur les langages C et C++, support des nouveaux CPU, amélioration de la prise en charge de Rust, etc.

La 15.1 poursuit les diverses améliorations sur Cobol, Rust (notamment pour gccrs), support de C 23 par défaut, amélioration du support des AMD Zen 5 et Xeon 7 Diamond Rapids ou encore sur les extensions AVX d'Intel. Cette version confirme le retrait définitif du support des Xeon Phi. 

La liste des modifications des 15.0 et 15.1 est à consulter ici : https://gcc.gnu.org/gcc-15/changes.html

Postman est utilisé par des millions de développeurs pour gérer et tester les API. Plusieurs souscriptions sont disponibles dont un plan gratuit (très) limité. Il a un bon support, une documentation très complète et une évolution régulière. 

Deux alternatives open source peuvent remplacer Postman : Bruno et Requestly. Bruno se veut plus simple que Postman, il est open source avec une interface simplifiée, une administration complète, un mode déconnecté, intégration avec Git. Il se veut aussi plus léger et plus performant. Il est disponible en souscription gratuite ou payante, mais moins chère que Postman.

Requestly se veut plus complet que Bruno. Il peut intercepter les requêtes API, modifier les headers, créer des mocks API, support multi-navigateur via des extensions. Toutes les fonctionnalités sont accessibles gratuitement. Il est encore jeune et manque d'intégration avec les outils tiers. 

Bruno : https://github.com/usebruno/bruno

Requestly : https://requestly.com/

Comparatif (souce : dev.to) :

Vitalik Buterin, cocréateur d'Ethereum, a publié sur Ethereum Magicians, une surprenante proposition : remplacer EVM, au coeur de la cryptomonnaie par du RISC-V. Il s'agit de changer la couche d'exécution d'Ethereum pour la montée en charge, la disponibilité et l'indépendance technologique. EVM est utilisé pour exécuter les contrats. Selon le développeur, ce changement pourrait être bénéfique et améliorera l'exécution de la plateforme et assurer une montée en charge plus forte.

Il met en avant l'écriture des contrats en Rust et d'ajouter le support RISC-V dans le backendet unifier, à terme, les contrats. Vitalik précise sur les contrats actuels sous EVM continueront à fonctionner pour garantir le bon fonctionnement de la plateforme. Pour le moment, il préconise de remplacer ZK-EVM et non l'ensemble d'EVM. Il précise que plusieurs solutions techniques pour être utilisées pour cette migration. Une des possibilités est de déployer RISC-V au côté d'EVM pour migrer en douceur. L'autre solution plus radicale est de convertir tous les contrats EVM existants en utilisant un interpréteur écrit en RUST et exécuté sur du RISC-V.

Post : https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617

Quelles tendances à suivre dans le développement web en 2025 ? Greatworks propose son top 10 :

1 / IA : sans surprise, l'IA s'intègre dans le développement web dans les fonctionnalités et dans les outils de développement

2 / PWA : cette approche reste une référence pour concevoir des apps web et éviter de faire du natif. Le PWA permet d'aller plus vite dans les projets d'apps mobiles

3 / serverless : réduire la complexité des architecture et de l'infrastructure

4 / WebAssembly : pour profiter des langages avancés directement sur le navigateur

5 / Single Page Applications : toujours là. Ce n'est pas forcément le design de référence mais le SPA reste bien présente

6 / Interface vocale

7 / micro-intéraction et tout ce qui est Motion UI : pas forcément la tendance que nous aurions mis en avant

8 / technologie 5G : pour améliorer les performances et l'expérience mobile

9 / blockchain pour la sécurité : là encore pas forcément une approche attendue. Il faudrait déjà faire de la sécurité par conception sur tous les projets web

10 / des développements web plus sobre, moins gros et minisant les ressources et le poids des assets 

Une journée dédiée à C++ : Pure Virtual C++. Elle aurait lieu le 30 avril prochain à partir de 14h. Le programme s'annonce intéressant : les performances en C++ 23, développement multiplateforme, debugging dynamique, les dernières améliorations sur VS Code et Visual Studio, proxy, les modules en C++

Agenda : https://devblogs.microsoft.com/cppblog/pure-virtual-cpp-2025-pre-conference-videos/

Les vidéos de pré-conférence sont disponibles : https://www.youtube.com/playlist?list=PLReL099Y5nRfLGBGRHml5WE81yk2OxdVU

Doom est devenu une référence pour les portages les plus insolites. Pourquoi ne pas y jouer sur son outil htop (monitoring de CPU)... C'est le défi du projet doom-htop. Bien entendu il ne faut pas s'attendre à un graphisme de folie, l'affichage se fait en ASCI. Et il est jouable ou presque. Il a été testé sur une distribution Ubuntu. Pour fonctionner, il lui faut un fichier WAD.

Le portage repose sur doomgeneric qui a été forké par le développeur. Doomgeneric a été proté sur Windows, X11, SDL, etc. 

A découvrir : https://github.com/0x0mer/doom-htop

Merci à Laurent B. pour la référence. 

Version 3.0, version 3.1.125, version bêta, RC, GM, etc. Il est toujours utile de revenir aux fondamentaux de la sémantique des versions. Prenons un exemple : version 1.1.20

1.x.x -> numérotion de la version majeure

x.1.x -> numérotation mineure

x.x.20 -> patch, bug fix

Dans cet exemple, nous avons 3 éléments. La version majeure change quand les changement sont importants. Dans ce cas, on justifie le changement de numéro. Dans le cas de Python, nous avons la release 2 et la release 3. Le second numéro concerne le plus souvent les mises à jour dites mineures. Ce sont souvent des ajustements, des fonctionnalités qui ne sont pas considérés comme majeures. Le dernier numéro est souvent utilisé pour les mises à jour de sécurité, des corrections de bugs, etc. Généralement, il n'y a pas de nouvelles fonctionnalités.

Il existe parfois d'autres sous-versions.

Au-delà, on parle d'alpha, preview, bêta, RC, release, GA, build. Cela indique un état non final de la version. Prenons un exemple : OpenJDK 25 build 19.

OpenJDK : nom du langage, du logiciel, etc.

25 : version majeure

build 19 : indique une pré-version en développement et c'est la 19e version buildée et distribuée.

Il est même possible d'ajouter à la numéroté un état du développement  : preview, b pour bêta ou rc pour release candidate.

Pour certains projets, on parlera de canaux (channels) de versions. Chromium utilise sur les versions desktop 4 canaux différents. Chaque canal correspond à un état de développement :

- canary : pré-version buildée chaque nuit, réservée aux développeurs expérimentés

- dev : version plus avancée et plus stable

- beta : version plus table et complète pour tests élargis mais pas pour la production

- stable : branche de la version finale et stabilisée pour tous les utilisateurs

Revenons à nos alpha, bêta, RC, release / GA / GM. Les alpha, bêta ou preview sont les versions en développement pour une audience plus ou moins élargie. La RC (release candidate) est une version pré-finale : les fonctionnalités sont complètes et il s'agit de trouver et fixer les derniers bugs. Plusieurs RC peuvent être distribuées. L'ultime étape est la version finale qui peut prendre différent nom selon le logiciel ou le projet : release, GA, GM, stable. Sur Azure, on parlera de GA (disponibilité générale) et non de release finale ou de version 1.0. 

Attention : l’identifiant de version majeure zéro (0.y.z) est destiné au développement initial. Tout ou partie peut être modifié à tout moment. L’API publique ne devrait pas être considérée comme stable. (règle 4 du semver)

En reprenant la définition du semver.org :

Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter :

1. le numéro de version MAJEUR quand il y a des changements non rétrocompatibles,
2. le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles,
3. le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétrocompatibles.

Des libellés supplémentaires peuvent être ajoutés pour les versions de pré-livraison et pour des méta-données de construction sous forme d’extension du format MAJEURE.MINEURE.CORRECTIF.

Le ministère de la justice pourrait exiger le démanetèlement pur et simple de Google, du moins se séparer de Chrome ! Un nouveau procès s'est ouvert le 21 avril pour position dominante. Google et la partie anti-trust du département de la justice américaine vont argumenter devant le juge fédéral en charge du dossier. Cette affaire est indépendante d'une autre action sur la position dominante de Google dans la publicité en ligne. 

Les arguments sont classiques : monopole sur le marché, une innovation limitée, le manque de choix pour les utilisateurs. Bien entendu, côté Google, les demandes apparaissent radicales et pouvant nuire à l'économie américaine. 

Au-delà de ces débats au tribunal, la perspective d'une séparation forcée de Chrome d'Alphabet / Google fait réagir plusieurs éditeurs pour un achat. Hier, on évoquait l'intérêt d'OpenAI pour acheter Chrome. Aujourd'hui, Yahoo! (si, si, Yahoo! n'est pas totalement mort) ne dira pas non !

Google pourrait aussi créer une société dédiée et séparer les activités. 

Sortez le pop-corn. 

Aujourd'hui, les entreprises font face à un double défi : garantir un haut niveau de sécurité tout en stimulant l'innovation logicielle. Pourtant, face à des cybermenaces toujours plus sophistiquées, l’approche « Shift Left » ne suffit plus à maintenir cet équilibre. Les équipes de développement ont besoin d’une approche plus globale afin d'assurer une sécurité optimale à chaque étape du cycle de développement logiciel, y compris lors des phases d’exécution et de déploiement. Depuis plusieurs années, l'approche « Shift Left » a permis aux équipes d’intégrer la sécurité en amont dans le cycle de développement logiciel, dès les premières phases. En intégrant directement des stratégies et outils de sécurité dans une plateforme de développement logiciel, chaque application bénéficie des mêmes garde-fous, garantissant ainsi une conformité uniforme aux normes de sécurité.

Cependant, cette approche a aussi introduit de nouvelles contraintes pour les équipes chargées du suivi. À mesure que les applications passent du développement à la mise en production, les efforts des développeurs en matière de sécurité ne sont pas toujours maintenus tout au long du cycle de vie des applications.

Aller au-delà de la sécurité en amont

Lors de la mise en place d'une plateforme de développement logiciel, une entreprise peut définir des modèles d'outils et des workflows conformes aux exigences de sécurité avec des stratégies intégrées. Ces workflows sont appliqués aux projets et les outils deviennent accessibles à l’ensemble des équipes. Cela permet de réduire ainsi les efforts redondants et les coûts indirects, tout en instaurant une approche proactive et globale de la sécurité sur l’ensemble du portefeuille logiciel. La sécurité reste l'affaire de tous, la faire évoluer vers des niveaux supérieurs de la pile technologique (approche « Shift-Up »)  permet une meilleure surveillance et une application plus homogène des règles de sécurité à l’échelle de l’entreprise. Surtout, cette approche garantit que les mesures de sécurité restent intégrées dans chaque projet, de la première ligne de code jusqu’à la production et au-delà.

Pourquoi privilégier une approche de sécurité intégrée au niveau de l'application ?

Alors que l’approche « Shift Left » vise à protéger le code dès les premières phases du développement, le modèle  « Shift Up » garantit l’extension de ces mesures de sécurité aux étapes ultérieures, comme le déploiement, l’environnement d’exécution et la post-release. Grâce à cette stratégie, les entreprises peuvent réduire considérablement les vulnérabilités en production et mieux anticiper leur gestion.

L’intégration précoce des protocoles de sécurité assure la conformité de toutes les activités de développement aux exigences réglementaires, limitant ainsi les risques d’amendes, de sanctions et tout autre impact négatif. Un logiciel plus sécurisé renforce également la confiance des clients, des partenaires et des parties prenantes, améliorant ainsi la réputation et la compétitivité de l’entreprise.

Voici trois mesures que les responsables du développement peuvent adopter pour faire évoluer l’approche « Shift Left » et sécuriser l’ensemble du cycle de développement logiciel :

1.   Développer des analyseurs de sécurité automatisés et réutilisables

Les équipes doivent concevoir des composants de test de sécurité automatisés, réutilisables et adaptables à différents projets et architectures d'application, au sein d'un environnement d'intégration continue (CI). Par exemple, la création de composants pour les tests statiques de sécurité des applications (SAST), les tests dynamiques de sécurité des applications (DAST), l'analyse des dépendances et l'analyse des conteneurs garantit la cohérence et limite la duplication des efforts.

L’introduction d’une couche d’abstraction entre les analyseurs de sécurité et leurs implémentations permet de standardiser les résultats avant qu’ils n’atteignent les équipes de développement. Cela centralise le contrôle des règles et des configurations de sécurité, facilitant l’ajout, le remplacement ou la mise à jour d’analyseurs de sécurité sans perturber les workflows. À long terme, cette approche offre aux entreprises un cadre de sécurité flexible et évolutif, capable de s’adapter aux exigences changeantes tout en maintenant une posture de sécurité unifiée à l’échelle de l’entreprise.

2.   Établir des stratégies de sécurité globales comme garde-fou

Il est essentiel d’établir des directives et des protocoles généraux pour normaliser les pratiques de sécurité dans tous les projets et équipes d’une entreprise. Ces stratégies jouent un rôle de garde-fou en fournissant un cadre structuré qui garantit un niveau de sécurité cohérent tout en laissant une certaine flexibilité pour s’adapter aux besoins spécifiques des projets.

La première étape consiste à définir les seuils de tolérance aux risques. Une fois ces seuils établis, des stratégies de sécurité conformes aux exigences réglementaires et aux normes internes doivent être mises en place. Ces stratégies doivent inclure des tâches obligatoires, appliquées automatiquement à tous les projets, telles que l’exécution de scans de sécurité. Conçues de manière modulaire, elles simplifient la gestion du portefeuille logiciel et permettent une adaptation plus agile aux divers besoins.

3.   Instaurer des contrôles d'approbation contextuels

Une fois les stratégies de sécurité mises en place, l’étape suivante consiste à bloquer la promotion du code lorsque des outils de sécurité détectent des vulnérabilités ou des risques inacceptables. Les résultats doivent être communiqués aux équipes de développement, et les portes d’approbation ne doivent être activées qu’en cas de nécessité.

Par exemple, si un scanner SAST identifie une vulnérabilité critique, le développeur doit soit la corriger, soit obtenir l’approbation de l’équipe de sécurité avant de poursuivre. En revanche, si aucune vulnérabilité n’est détectée ou si le seuil de tolérance au risque est respecté, le développement peut se poursuivre sans interruption. Cette approche permet de préserver la productivité des équipes tout en encourageant des pratiques de sécurité rigoureuses.

L’approche « Shift-Up » dépasse celle du « Shift Left » en intégrant des mesures de sécurité pérennes tout au long du cycle de développement logiciel. Elle permet de réduire les vulnérabilités, d’assurer la conformité et de renforcer la confiance grâce à l’automatisation des contrôles, des stratégies de sécurité globales et des processus d’approbation contextuels. Elle incarne une stratégie proactive et durable en matière de sécurité logicielle, essentielle pour les entreprises qui souhaitent maintenir l'équilibre entre sécurité et innovation rapide.

Vice-Président EMEA de GitLab

L'index TIOBE d'avril 2025 est disponible. Le podium est dans l'ordre : Python, C++ et C. Seul changement : C++ repasse devant C. Python pèse un quart des recherches sur les différents moteurs de recherches et sites de référence.

Dans le top 10, peu de changement : Delphi est 9, gagnant 2 places. SQL est 10e, perdant une place.

Python

C++

C

Java

C#

JavaScript

Go

Visual Basic

Delphi

SQL

R et Ada progressent fortement, PHP regagne 4 places.

Rappelons que cet index se base sur les requêtes et recherches. Il ne définit pas la popularité et l'usage réel de tel ou tel langage. 

En comparaison, GitHub publie chaque année son Octoverse. Le top 5 des langages les plus utilisés sur la plate forme est : JavaScript, Python, Java, TypeScript, C#

Le meetup Python Grenoble organise une soirée sur le thème "découvrir le craft Python par la pratique". 

Ce coding dojo est une invitation à découvrir ou redécouvrir les bonnes pratiques de développement en Python à travers la réalisation collective d’un projet simple. L’objectif n’est pas de produire un logiciel parfait, mais de progresser ensemble sur des notions clés du craft : lisibilité du code, découpage logique, tests, et design orienté objets. 

29 avril à Grenoble, à partir de 19h

Page du meetup : https://www.meetup.com/groupe-dutilisateurs-python-grenoble/events/307434071/

QEMU, environnement de virtuailisation, est disponible en version 10. Il peut exécuter de multiples OS et émulent plusieurs platesformes matérielles. Les nouveautés sont nombreuses :

- sur ARM, de nouvelles fonctions CPU sont supportés : FEAT_AFP, FEAT_RPRES, FEAT_XS

- sur RISC-V : le support de l'architecture RISC-V s'étend avec risc-v-iommu-sys, extension svukte, les extensions ssstateen, support sha, support de nouvelles CPU, dépréciation de la machine par défaut RISC-V

Sur LoongArch, Qemu, avec KVM, permet de faire du chargement à chaud des CPU. De nouvelles CPU Intel sont incluses dans la v10. Sur le Mac, l'accélération graphique est possible avec un host macOS. Cette fonction est valable sur les modèles Apple Silicon et Intel. 

Release note : https://wiki.qemu.org/ChangeLog/10.0

Elecrow lancera très bientôt une campagne de financement pour sa valise de prototypage rapide, Crow Pi 3. Ce boîtier contient une Pi, un écran 4,3'' et de nombreux capteurs : breadboard, capteur de luminosité, tilt, capteur ultrason, moteur de vibration, capteur tactile, etc. Les GPIO sont directement accessibles. Il est même possible d'installer une micro:bit, une Pico ou une Arduino Nano.

L'écran principale est un LCD 4,3'' mais on dispose aussi d'un écran 1,6''. L'écran principal est trop petit pour être réélement utilisé pour le codage des capteurs. La CrowPi 2, toujours disponible, utilise un écran bien plus grand : 11,6''. 

Le projet se propose aussi d'être une plateforme de découverte de l'IA avec DeepSeek, OpenAI et Gemini...

Le tarif n'est pas encore indiqué, espérons qu'il soit inférieur à la version 2. 

JFrog a publié rson rapport Software Supply Chain State of the Union 2025. Il dresse un panorama de la sécurité sur les plateformes de supply chain logiciels. Cette dernière étude confirme les problèmes de sécurité autour de l'IA et des modèles LLM qui ne cessent de progresser. 

"De nombreuses organisations adoptent avec enthousiasme les modèles ML publics pour stimuler l'innovation rapide, démontrant un engagement fort à exploiter l'IA pour la croissance. Cependant, plus d'un tiers d'entre elles comptent encore sur des efforts manuels pour gérer l'accès aux modèles sécurisés et approuvés, ce qui peut conduire à des négligences potentielles," a déclaré Yoav Landman, CTO et co-fondateur de JFrog. "L'adoption de l'IA va croître encore plus rapidement. Par conséquent, pour que les organisations prospèrent à l'ère de l'IA, elles doivent automatiser leurs chaînes d'outils et leurs processus de gouvernance avec des solutions prêtes pour l'IA, garantissant qu'elles restent à la fois sécurisées et agiles tout en maximisant leur potentiel d'innovation."

Principaux éléments du rapport :

• une combinaison de vulnérabilités de sécurité menace la chaîne d'approvisionnement logicielle : on peut citer les multiples CVE, les packages malveillants (qui se multiplient partout), les expositions de secrets, et les mauvaises configurations/erreurs humaines. Par exemple, l’équipe de recherche en sécurité de JFrog a détecté 25 229 secrets/tokens exposés dans des registres publics (augmentation de 64 % par rapport à l'année précédente). La complexité croissante des menaces de sécurité logicielle rend plus difficile le maintien d’une sécurité cohérente dans la chaîne d'approvisionnement logicielle.
• La prolifération et les attaques des modèles AI/ML augmentent : En 2024, plus de 1 million de nouveaux modèles ML ont été ajoutés sur Hugging Face, accompagnés d'une augmentation de 6,5x des modèles malveillants, ce qui indique que les modèles AI et ML deviennent de plus en plus une cible privilégiée pour les acteurs malveillants.
• La gouvernance manuelle des modèles ML augmente les risques : la majorité des entreprises (94 %) utilisent des listes certifiées pour gouverner l'utilisation des artefacts ML, mais plus d'un tiers (37 %) de ces entreprises s'appuient sur des efforts manuels pour créer et maintenir leurs listes de modèles ML approuvés. Cette dépendance excessive à la validation manuelle crée de l'incertitude sur l'exactitude et la cohérence de la sécurité des modèles ML.

• Le manque de scans de sécurité est un véritable angle mort : la situation est à la fois alarmante et incomphérensible ! Seulement 43 % des professions de l'IT disent que leur entreprises réalisent des scans de sécurité à la fois sur le code et les binaires. Il y a un mieux par rapport à 2024 mais ce n'est pas glorieux pour les entreprises

• Les vulnérabilités critiques continuent d'augmenter : En 2024, les chercheurs en sécurité ont divulgué plus de 33 000 nouveaux CVE, soit une augmentation de 27 % par rapport à 2023, dépassant le taux de croissance de 24,5 % des nouveaux packages logiciels. Cette tendance soulève des inquiétudes car le nombre croissant de CVE augmente la complexité et la pression sur les développeurs et les équipes de sécurité, pouvant freiner l'innovation. Par ailleurs, l’équipe de sécurité de JFrog a constaté que seulement 12 % des CVE de haut niveau notées "critiques" (CVSS 9.0-10.0) par les organisations gouvernementales justifient le niveau de sévérité critique qui leur a été attribué, car elles sont susceptibles d'être exploitées par des attaquants₁. Ce modèle est préoccupant en raison d'une méthodologie de notation centralisée et inchangée au fil du temps, ce qui augmente le risque de faux positifs dans les évaluations et contribue à la "fatigue de vulnérabilité" chez les développeurs.

  Le manque de visibilité sur l'origine des codes utilisés est toujours d'actualité (le vibe coding va contribuer à faire exploser ce problème) et constitue une réelle menace pour l'intégrité des apps. Tout comme, il est totalement anormal de télécharger des extensions et des templates pour son IDE sans un minimum de vérification. 

  Les hacks et vulnérabilités concernent les OS, les langages, les frameworks, les codes ! 

La mort du mainframe, et du Cobol, est annoncée chaque année depuis 25 ans. En automne 2024, Rocket Software, avec le cabinet Forrester, avait mené une étude auprès de 300 responsables IA, surtout aux Etats-Unis autour du mainframe et de la modernisation des applications. Résultat : le refactoring d'apps mainframe échouent souvent dès les premières tentatives. Le constat est sévère : 90 % des tentatives de réécriture échouent et 50 % des répondants affirment que les échecs successifs freinent ou ont freiné toute tentative de transformation de l'IT et des assets techniques. 

Plusieurs causes sont cités par l'étude :

- un manque de compétences mainframe, Cobol et sur toutes les couches liées

- complexité de l'environnement legacy et une stratégie trop complexe

Moderniser un environnement mainframe / cobol / système z est tout sauf facile. Dire le contraire c'est méconnaître la réalité ou alors il s'agit de petits projets non critiques. Et encore, ces projets peuvent être lancés si les équipes savent ce qu'il y a réellement dans la boîte car parfois la documentation technique n'existe pas, aucune cartographie des couches et des applications existe, etc. 

Au lieu de tenter une modernisation profonde, elle consiste à faire cohabiter le mainframe / cobol avec des environnements modernes. Une approche hybride est le plus souvent déployée, une minorité d'entreprises décide de déprovisionner le mainframe et une partie des applications liées. 

Réécrire les applications ? C'est souvent un saut vers l'inconnu et le chantier peut se révéler particulièrement complexe. Et les échecs sont nombreux. Redévelopper de zéro ? Toujours possible mais c'est long, difficile et hasardeux, surtout si le fonctionnement du legacy est mal compris et que la cartographie de l'application n'est pas fiable, ni complète. Une application Cobol (ou autre) peut avoir des dizaines, voire, des centaines de dépendances avec d'autres services et applicatifs. 

Parmi les défis avant toute modernisation :

- comprendre (réellement) son système legecy

- avoir les bonnes compétences

- penser aux données, aux modèles de données : bref, quid de la migration des données, des bases, des tables, etc. ?

- Quels risques pésent sur le bon fonctionnement de l'entreprise ?

- définir un budget et une planning réaliste : une modernisation peut coûter très cher et durer plusieurs années. Une vision long terme est cruciale.

- avoir une architecture de modernisation claire et définie avant de lancer le chantier et ne pas en changer tous les 6 mois

Fin mars, Juan Lucas Barbier (un expert en modernisation et en systèmes mainframe) a raconté comment un projet de modernisation s'est crashé après 2 ans d'efforts. Le constat est sévère mais doit faire réflêchir : un DSI qui part et met à jour son CV, 2 années perdues et 70 millions $ dépensés pour pas grand chose... Barbier a vu trop de responsables IT et de dirigeants dire qu'ils vont tout moderniser, enterrer le mainframe et déployer une belle transformation numérique. Il rappelle un simple chiffre : 70 % des projets de modernisation du legacy échouent lamentablement. 

Les conséquences sont parfois catastrophiques :

- 40 % de surcoût qui pèsent sur le budget IT et bloquent d'autres chantiers et investissements

- à peine 50 % des promesses de modernisation sont réellement réalisés

Il rappelle un fait que nous répétons sans cesse depuis 20 ans à Programmez! : le mainframe et Cobol oui c'est moche, peu intéressant mais ils fonctionnement. Les transactions bancaires reposent sur ces systèmes. Des millions de lignes de code sont écrites chaque année pour maintenir et mettre à jour les apps Cobol.

Mais pourquoi autant d'échecs ? Barbier tire, de son expérience, 3 remarques :

- certains consultants, dirigeants et DSI disent : ce n'est que du code... Puis il découvrent la plomberie : les règles métiers, les dépendances, tout ce qui n'est pas documenté et parfois des applications que personne ne sait à quoi elles servent mais elles sont là

- le syndrome du PowerPoint vs réalité : le remède (= la modernisation) peut être pire que la maladie (= mainframe / cobol)

- on fonce et on casse tout : le risque est de détruire des systèmes qui fonctionnement parfaitement. Une approche plus douce serait préférable pour migrer certains assets et garder ce qui fonctionne

Barbier n'est pas contre la modernisation mais pour lui, les entreprises qui réussissent la modernisation savent faire des compromis : si le core code fonctionne parfaitement, il ne faut pas y toucher. Le focus est mis sur l'intégration, les API, migrer ce qui est migrable sans casse. Tous les changements doivent être mesurés : le fameux ROI. 

Vous savez quoi ? Ce constat peut être à toutes applications PHP, Java, C#, C++ qui sont là depuis 10, 15, 20 ans...

Level 2 Jeff a proposé un défi sur sa chaîne YouTube : dépixelisation des images d'une vidéo. A la clé : 50 $. L'image était fortement pixelisée rendant toute identification impossible. Sauf qu'il n'a fallu que quelques heures pour réussir le défi ! KokuToru a publié sur son GitHub les méthodes utilisés. Ce qui est intéressant est l'approche différente (et complémentaire) entre les deux solutions du hacker. La première est une "attaque" par force brutale. Le plus difficile est de pouvir s'appuyer sur une image stable visible dans la vidéo du défi.

Dans la solution 1, le développeur utilise du TensorFlow pour extraire les pixels et toutes les données possibles de l'image puis de agréger pour tenter de reconstituer l'image. Il fallait extraire les frames avec ffmpeg puis les traiter par un templare. Cet test 1 repose sur 56 frames. Le résultat est loin d'être parfait mais avec un peu de concentration on peut lire certaines informations (l'image contenu le contenu d'un SSD).

La solution 2 se révèle bien plus puissante. Elle mêle algo, ffmpeg et GIMP. Comme le dit KokuToru, le test 2 s'appuie sur les principes du test 1 en trouvant une position dans la fenêtre automatiquement pour améliorer le traitement et avoir plus de données. Cette approche a permis d'extraire 200 frames. 

Et là, le résultat est beaucoup plus précis et surtout la dépixelisation permet une lecture facile du contenu !

Il a fallu à peine 4 heures pour aboutir à ces résultats.

Comme le dit Jeff, il aurait fallu un supercalculateur il y a quelques années. Aujourd'hui, entre l'IA et les outils disponibles, il est possible d'aller beaucoup plus vite même quand il s'agit d'une vidéo floutée. Pour Jeff, le fait d'avoir déplacé la fenêtre contenant les données à lire a permis de générer des données et des frames supplémentaires. Il ne pense plus appliquer un simple flou ou un effet de pixelisation à l'avenir. 

"La morale de l'histoire, c'est que si vous ne voulez pas que les gens lisent des données censurées… ne les publiez pas en ligne." conclut Jeff. 

Post de Jeff sur le travail de KokuToru : https://www.jeffgeerling.com/blog/2025/its-easier-ever-de-censor-videos

Les solutions de KokuToru : https://github.com/KoKuToru/de-pixelate_gaV-O6NPWrI?tab=readme-ov-file

Quelle surprise ! Une récente étude d'Azul indique que 83 % des DSI ayant répondus à l'étude disent dépenser plus que prévu dans les services cloud. Bref, il y a décalage entre le prévisionnel et la réalité. Pis, la moitié des DSI affirme que les dépenses cloud dépassent +25 %... Seulement 2 % affirme dépenser moins que prévu. 

Pourquoi un tel différentiel : le manque d'anticipation de certains workloads, la difficulté à maîtriser la complexe tarification du cloud, l'IA. Cependant, cela ne devrait pas empêcher le cloud de s'étendre et d'être toujours plus présent dans les entreprises.

Les débats sur les claviers sont sans fins. Personnellement, rien ne vaut les claviers mécaniques des années 80 et 90 pour la qualité de la frappe, le ressenti à la frappe, le caractère précis de la pression.

Cherry annonce un nouveau modèle de switch : le MX Northern Light. « C’est notre commutateur linéaire le plus abouti à ce jour, conçu pour celles et ceux qui nous ont inspirés », déclare Joakim Jansson, Head of Product Manager CHERRY. « MX Northern Light illustre parfaitement ce qui se passe quand CHERRY écoute sa communauté et repousse les limites de la précision mécanique. »

Avec cette annonce, Cherry propose un pack inédit : un clavier compact et un tapis souris dédié. 

Equipé de la dernière technologie MX2A, le switch intègre :

GitLab annonce que son service Duo est disponible avec Amazon Q. Cette solution intégrée est proposée en bundle aux clients GitLab Ultimate sur AWS. Cette version embarque directement les agents Amazon Q Developer au sein de la plateforme GitLab.

Pour GitLab, cette intégration répond à plusieurs défis :

●    Le développement autonome de nouvelles fonctionnalités
Transformation automatique des idées de fonctionnalités en merge requests prêtes à être intégrées, en quelques minutes : analyse des besoins, planification, et génération de merge requests conformes aux standards internes.

●    La modernisation des bases de code existantes
Automatisation de la refonte de bases de code Java 8 et 11 : création d’un plan de mise à niveau complet, génération de merge requests documentées avec traçabilité.

●    La remédiation des vulnérabilités de sécurité
Explication des failles, analyse des causes racines, et remédiation en un clic via des suggestions de modifications de code.

●    L’amélioration de l’assurance qualité
Génération automatique de revues de code pour améliorer la couverture de tests et la cohérence de qualité tout en réduisant la charge manuelle.

●    L’optimisation des revues de code
Accélération des cycles de relecture grâce à des retours en ligne, des suggestions d’amélioration et des alertes sur les performances et la sécurité.

FerretDB se présente comme une alternative open source à MongoDB. Il peut utiliser les pilotes MongoDB avec PostgreSQL. L'environnement se base justement sur PostgreSQL, comme SGBD backend. L'idée de FerretDB est de pouvoir utiliser les mêmes outils, pilotes, langage de requête que MongoDB. 

La motivation de FerretDB est de proposer une solution compatible open source et évite d'utiliser les fonctions avancées de MongoDB. FerretDB annonce une compatibilité avec les pilotes et les outils de MongoDB, à partir de la v5.x et le projet vise à améliorer les performances et à suivre les évolutions de MongoDB au fur et à mesure.

Cela signifie une roadmap fonctionnelle chargées. Chaque trimestre, une version apporte son lot de nouveautés. Pour le 1er trimestre, la version 2 est arrivée : licence Apache 2, support payant pour les entreprises, FerretDB cloud (sur AWS, GPC et Azure très bientôt). La 2.1.0 a été déployée el 3 avril avec des corrections de bugs et des performances améliorées sur DocumentDB. 

Pour en savoir plus : https://www.ferretdb.com/

La datagrid est un des objets d'interface les plus utilisés mais aussi parfois le moins pratique. Handsontable est une datagrid en JavaScript reprenant l'ergonomie d'un tableur. Il peut s'utiliser en JavaScript, TypeScript, React, Angular, Vue. Son apparence tableur est faite pour être plus familier aux développeurs et aux utilisateurs. Il permet d'éditer, de saisir, de modifier les données. On peut injecter toutes sortes de sources de données. 

La personnalisation est poussée : différents thèmes, API flexibles, internationalisation, raccourcis clavier, 400 formules de calculs, validation des données, fusion des cellules, etc. 

Installation ultra simple : npm install handsontable

Le projet est disponible en version 15.2.0. Cette version met en avant la stabilité et les performances. Le plugin filtre a été réécrit, la traduction a été améliorée en supportant totalement le Farsi. 

Note de version de la 15.2.0 : https://handsontable.com/blog/handsontable-15.2.0-stability-improvements

GitHub : https://github.com/handsontable/handsontable?tab=readme-ov-file

Fascinant ou inquiétant, un semi-marathon à Pékin un peu particulier a eu lieu : 21 robots humanoïdes ont courru la longueur du semi-marathon, soit 21 km. Il faut voir cette course comme une démonstration technologique pour la Chine. Tous les robots sont issus d'entreprises et de centres de recherches du pays. 

Cette course dédiée se tenait en parallèle à la course "réelle" avec 12 000 participants. Le parcours n'était pas le même car plusieurs typs de terrains ont été mis en place pour éprouver les robots et leurs capacités.

Plusieurs robots n'ont pas pu terminés : chutes, pannes de batteries. Il fallait que les robots courent ou marchent sur 2 pieds. Une équipe technique se tenait près de chaque robot pour les contrôler si besoin. 

La Chine a de grandes ambitions dans la robotique.

JetBrains annonce IntelliJ Scala Plugin 2025.1. Le principal intérêt de cette version est le support de nouvelles fonctionnalités de Scala 3. Scala est un langage fonctionnel. L'éditeur met à niveau son plug-in :

- support de la nouvelle syntaxe de Scala 3.6 sur les contexts bounds et givens. Pour faire simple, avant, il n'était pas possible de renommer un contexte à la même place où il a été défini. Le nouveau paramètre implicite permet de lever cette limitation.

- support de named tuples : avec Scala 3.7, le langage stabilise cette syntaxe

- meilleur rapport sur les erreurs

- fixation d'un bug ancien dans le debugger 

- poursuite du support des macros Scala

- meilleure complétion de code

Annonce : https://blog.jetbrains.com/scala/2025/04/16/intellij-scala-plugin-2025-1-is-out/

NVIDIA avait corrigée la vulnérabilité CVE-2024-0132 avec un joli score de 9 dans le niveau critique. La correction se révèle incomplète et permet, en cas d'exploitation réussie, de mettre les données en danger. Cette faille permet d'avoir un accès non autorisée d'un conteneur. La vulnérabilité avait été dévoilée en septembre 2024 et rapidement patchée. Trend Micro a vérifié la résolution et conclut que le fix proposé n'est pas complet et qu'une faille est toujours présente. 

Elle concerne Docker sur Linux et permet de faire un déni de service. La faille est numérotée CVE-2025-23359. Plus grave, cette faille peut exposer les infrastructures et les données. Trend Micro a publié une analyse de la faille et propose même un exemple d'utilisation. 

En attendant une correction complète, Trend Micro conseille :

- réduire les accès API Docker

- désactiver tout ce qui n'est pas essentiel

- mettre en place un contrôle d'accès plus strict

- faire un audit des conteneurs et des interactions avec le système

Pour en savoir plus : https://www.trendmicro.com/en_us/research/25/d/incomplete-nvidia-patch.html

Alors que la version 5.3.4 avait été déployée le 3 avril dernier, la 5.3.5 a déployé dès le 5. Une régression fonctionnelle dans Autoprefixer pouvait apparaître dans Firefox à cause d'une sortie CSS non attendue. Pour le régler, un bug fix a été rapidement préparé. 

Pour rappel la 5.3.4 fixait plusieurs bugs connus. 

Annonce : https://blog.getbootstrap.com/2025/04/04/bootstrap-5-3-5/

Grosse frayeur hier : l'arrêt du financement du programme CVE (Common Vulnerabilities and Exposures), une des bases de données références des failles et vulnérabilités. MITRE est à l'origine du projet. Mais le contrat liant MITRE et le développement de CVE devait prendre fin. Après quelques heures de confusion, il a été annoncé que le gouvernement fédéral américain continuerait à financer CVE au moins pour les 11 prochains mois. Entre l'annonce de la fin du financement et la reprise du financement, une certaine panique s'est emparée des communautés sécurité.

Sans doute une réorganisation du projet sera nécessaire pour assurer l'avenir de la base CVE qui recense des milliers des failles et qui est consultée par les développeurs, les experts en sécurité, les éditeurs, etc. 

PyCharm 2025.1 est une mise à jour majeure. L'éditeur annonce l'unification des différentes éditions en combinant les versions Community et Professional en une seule édition. Cela va simplifier la gamme incluant le support de Jupyter. Les fonctions de base sont gratuites, les fonctions avancées seront accessibles avec une souscription Pro. 

Cette version propose aussi Junie, un agent de codage créé par JetBrains. Il est disponible via JetBrains AI. Il peut écrire, corriger et tester du code. L'éditeur mise sur l'IA dans les différents IDE dont PyCharm. Pour faire tourner les projets de machine learning, nous pouvons maintenant utiliser Cadence, une infrastructure hardware en mode cloud et tout est fait pour simplifier son usage. Pour la manipulation des données, PyCharm introduit Data Wrangler. Pour la gestion des projets Python, l'outil introduit le support de Hatch. Il peut migrer automatiquement les configurations, créer des environnements isolés, etc. 

Côté PHP, PhpStorm 2025.1 est disponible. L'outil améliore les annotations, la complétation du code. Côté debug, l'outil simplifie la configuration de Xdebug. Par exemple si Xdebug n'est pas installé, PhpStorm s'en occupe... La version 2025.1 peut maintenant découvrir elle-même le chemin de son Worpress et l'ajouter automatiquement dans les paramètres. A noter aussi des évolutions sur le support de Vue et Nuxt. 

JetBrains a publié un post sur l'état actuel de K2 Mode dans IntelliJ IDEA 2025.1. L'éditeur a introduit une nouvelle implémentation de Kotlin. Il s'agit d'une évolution majeure pour le support de Kotlin dans l'IDE. Ce travail a permis d'améliorer les performances et surtout d'avoir une fondation solide pour les futures évolutions. 

K2 Mode est, comme le rappel l'éditeur, un effort de long terme sur le support du langage dans l'IDE. Cette nouvelle implémentation doit faciliter l'intégration des évolutions du langage plus rapidement et de manière plus stable. Et surtout, l'éditeur mise tout sur K2 : cela signifie que les nouvelles fonctionnalités de Kotlin seront disponibles que dans K2. Par défaut, IntelliJ IDEA 2025.1 propose par défaut K2 Mode. Il est aussi disponible sur Android Studio. 

Post complet : https://blog.jetbrains.com/idea/2025/04/k2-mode-in-intellij-idea-2025-1-current-state-and-faq/

Nous faisons le point sur l'actualité de Suse avec Cyril Cuvier. Nous parlerons IA, Rancher, Suse en France, etc.

VirtualBox 7.1.8 prépare l'arrivée du noyau Linux 6.14. Il s'agit pour le moment d'un 1er support. L'outil de virtualisation open source est disponible sur Linux, macOS et Windows. Le support de Linux 6.14 est possible sur les machines virtuelles Linux s'exécution sur VirtualBox. Cette version corrige aussi des bugs. 

Outre Linux 6.14, VirtualBox supporte aussi le noyau RHEL 9.4. 

Note de version : https://www.virtualbox.org/wiki/Changelog

Pinta est un logiciel de dessins et de retouches d'images open source. Il peut remplacer Paint ou Gimp, éventuellement Photoshop. La v3 est un changement majeur : nouvelle interface, plus moderne, plus cohérence, migration vers GTK4 et libadwaita. GTK est un ensemble complet pour créer des interfaces. La migration vers GTK4 a permis de remettre à niveau l'interface du logiciel. La v3 corrige des dizaines de bugs. 

La gestion des calques a été améliorée : par exemple, à la sauvegarde, on est enfin prévenu si un risque de fusion existe... Pinta 3 réintroduit les extensions. Et on bénéficie aussi de nouveaux effets et filtres. Cette v3 ajoute un installeur Arm64 sur Apple Silicon.

Site : https://www.pinta-project.com/

Python sait tout faire ou presque. Alors, pourquoi pas faire directement du Python sur les navigateurs ? Plusieurs outils permettent de le faire. Un des plus connus est brython (Browser Python).  Il s'agit d'une implémentation de Python 3 destinée à s'exécuter sur son navigateur. Brython supporte la syntaxe Python 3 et les modyles CPython. Il s'interface avec DOM et on insère le code Python dans les balives HTML5. 

Pour : Python 3, DOM

Contre : les performances, peu répandu, ne remplace pas tout le front

L'autre solution est de faire une transcompilation de Python vers JavaScript. C'est le principe de Transcrypt. Il promet de meilleures performances et un accès aux libs JS et même une intégration avec React. Transcrypt met en avant : la clarté de la syntaxe, la montée ne charge et le fait de passer par un seul langage. Site : https://www.transcrypt.org/

Pyodide est un portage de CPython vers WebAssembly / Emscripten. Il permet donc d'exécuter des packages Python sur le navigateur avec micropip. Il vient avec une interface JS - Python pour mixer les deux mondes en minisant les frictions. Site : https://pyodide.org/en/stable/

Bref, 3 outils, 3 approches différentes pour une même cible : faire tourner du code Python sur son navigateur.

Source : https://dev.to/maryalice/python-browser-compilers-5dg5 

Il y a 30 ans, les Amiga sombraient avec la faillite de Commodore. En 2025, des développeurs continuent à maintenir l'AmigaOS. Le 10 avril dernier, la version 3.2 update 3 a été déployée par le belge Hyperion Entertainment. AmigaOS 3.2 a été lancé en 2021. Cette version cible les modèles à processeur 680x0 et propose aussi des améliorations pour les cartes PiStorm. 

Cette version a connu des soucis de conception suite à problèmes financiers de l'éditeur. La 3.2.3 propose des couleurs en haute résolution, une refonte de nombreuses classes et API, un TextEditor plus souple avec la possibilité d'ajouter un menu personnalisé. La ROM KickStart arrive lui aussi en version 3.2.3. En tout, plus de 50 bugs ont été corrigés.

Cette mise à jour est disponible pour les utilisateurs enregistrés.  

Annonce : https://www.hyperion-entertainment.com/index.php/news/1-latest-news

.Net 10 est en plein développement. La Preview 3 est disponible depuis le 10 avril. Cette version propose de nombreuses évolutions : 

- introduction d'un AOT Safe Construction pour ValidationContext

- OpenTelemetry : support des Schema URL dans ActivitySource et Meter

- Dans la CLI --interactive devient interactif

- complétion dans les scriptions : dans la CLI

- support Microsoft Testing Platform dans dotnet test, CLI

- peu d'évolutions sur C# et F#, rien sur VB

- MAUI : des API sont dépréciées (ListView, Cell et TableView), sur Android, possibilité de faire de la lecture vidéo en plein écran, sur la partie Apple, support de Xcode 16.3

- Windows Form : correction de bugs

- WPF : correction de bugs, performances améliorées, nouveaux contrôles Fluent

Note de version complète : https://github.com/dotnet/core/tree/main/release-notes/10.0/preview/preview3

Google annonce Firebase Studio pour créer des apps  avec Firebase et Gemini. Firebase est un environnement utilisé par des millions de développeurs. Durant la conférence Next, Google a dévoilé Firebase Studio, en préversion pour le moment. C'est un outil cloud utilisant les agents IA et s'appuyant sur Gemini. Tout est fait pour pouvoir créer des applications IA de qualité. Pour Google, Firebase Studio est un mélange de Firebase et de Gemini. 

Pour faciliter le travail du développeur, plus de 60 modèles sont disponibles. Notre premier contact est un prompt pour définir ce que l'on veut créer. A partir du prompt, le studio propose une réponse cela convient, on peut lancer le prototype (bouton prototype thsi app). De là, une fenêtre éditeur s'affiche et on voit tout ce qui est généré. Quand le travail est fini, on peut visualiser le code et publier l'app. Attention : le déploiement nécessite un compte de facturation. La génération n'est pas forcément propre. Des erreurs apparaissent dans la génération. Plusieurs langages sont supportés. 

On peut créer du code, modifier un code existant, travailler avec nos outils. Il faut s'habituer un peu à l'interface mais Firebase Studio est plutôt bien pensé. 

Google introduit aussi un GenKit pour ajouter de la GenAI dans les apps Node, Python et Go. Il permet de construire des templates pour Firebase Studio. 

Annonce : https://cloud.google.com/blog/products/application-development/firebase-studio-lets-you-build-full-stack-ai-apps-with-gemini?hl=en

La communauté Python a rendez-vous du 30 octobre au 2 novembre à Lyon. Cette conférence est organisée par l'AFPy. La conférence se scinde en 2 parteis : 

- 30 & 31 octobre : Les développeurs et développeuses de différents projets open source se rejoignent pour coder ensemble. Chaque personne est la bienvenue pour contribuer, et nous cherchons également à accompagner les débutantes. Participez au développement de votre projet préféré !

- 1er & 2 2 novembre : journées dédiées aux conférences, bonnes pratiques et ateliers

Site : https://www.pycon.fr/2025/fr/

Veux-tu coder tes apps multiplateforme en Python et les déployer en Flutter ? C'est la promesse du framework Flet. Flet UI est construit sur Flutter mais cherche à en simplifier le développement et son utilisation. Flet simplifie aussi l'architecture : on utilise Python. Mais d'autres langages sont prévus : Go et C#. Pour l'utiliser : un éditeur de texte suffit (pas exemple nano). Il faut juste installer Python, Flutter, Flet, pas besoin de SDK supplémentaires. L'application générée sur mobile est une PWA.

Le projet est jeune. La v1 est attendue pour cette année. Actuellement, la 0.27 est utilisable. Flet est en développement depuis 3 ans. 

Flet se définit comme un framwork pour créer des apps web, desktop et mobile en utilisant Python, sans besoin de maîtriser le front. Les composants UI de Flet s'appuient sur Flutter. 

L'installation est rapide :

pip install flet

Attention : si vous êtes sur Mac, mettez pip3 et non pip (merci Python 3). Nous créons l'exemple counter.py, pour le run, nous passons par python3 county.py, et non le flet run.

Flet n'est pas sec ni complet mais l'idée de lier Python et Flutter. Maintenant, reste à passer en version stable et voir si la communauté suit ou non. 

Découvrir Flet : https://flet.dev/

OpenSSL passe en version 3.5.0. Cette version corrige quelques bugs mais la liste est courte. Mais attention : cette version apporte des changements qui peuvent casser les déploiements actuels. Réaliser un PoC avec de mettre à place.

Quelques changements : 

- pour les apps req, cms et smime, le projet utilise aes-256-cbc à la place de des-ede3-cbc

- les listes groupes TLS incluent les groupes hybrides PQC KME. Attention : les groupes non utilisés seront retirés de la liste par défaut

- support du serveur side QUIC

- nouveaux algos PQC

- toutes les fonctions BIO_meth_get_*() sont dépréciées

Note de version : https://github.com/openssl/openssl/releases/tag/openssl-3.5.0

FreeDOS est un OS compatible MS-DOS et les autres variantes de DOS. Il est open source. L'idée est de pouvoir utiliser les logiciels et les jeux MS-DOS et pourquoi pas écrire de nouveaux logiciels... 

La version 1.4 est le dernière en date. Cette version inclut une mise à jour de FreeCOM, un installeur et une aide au format HTML. La 1.4 améliore aussi FIDSK, JEMM, le ZIP, etc. Les nouveautés sont très intéressantes : https://freedos.org/download/announce.html

Vous pouvez l'installer sur une machine physique ou l'utiliser avec VirtualBox, 86Box, Qemu, etc. 

L'ANSSI publie toute sorte de conseils et de bonnes pratiques. Aujourd'hui, l'ANSSI te propose 10 règles d'hygiène numériqe pour son smartphone. 

Devoxx est le événement développeur du printemps. Durant 3 jours, des centaines de conférences vous attendent. Petite sélection de sessions :

- L’INTELLIGENCE ARTIFICIELLE N’EXISTE PAS : 16 avril à 9h

- LES LLMS REVENT-ILS DE CAVALIERS ÉLECTRIQUES ? : 18 avril à 9h35

- session "mode éco" dans son app avec le plugin flutter eco mode, 16 avril ) 13h

- session "Hacker-Proof : renforcez la sécurité de votre code en 15 minutes", 16 avril 12h35

- marre des null en Java, découvrez nullwaway, 17 avril à 17h

- coder avec peu, une session Nintendo ! 16 avril 10h30

- 30 ans d'hello world en java, 18 avril 10h30

- générateurs et itérateurs en Go, 16 avril 12h35

- booster le démarrage des apps Java, 17 avril à 11h35

- une librairie de composants UI sur mobile, 17 avril à 11h35

- TUI pour tout le monde, 17 avril, 13h30

-  Jib : Dockerless pour vos projets Java, 17 avril, 17h

- DuckDB, 18 avril à 10h30

Programmez! est partenaire média de Devoxx. Et nous serons présents sur le stand Technosaures avec beaucoup de surprises vintage !

Rendez-vous au stand G05

Site : https://www.devoxx.fr/

Tu aimes TypeScript ? Le meetup Paris TypeScript revient le 13 mai avec 3 sessions !

Talk #1 : Prise de parole en public, comment réussir son talk ?

Talk #2 : Tests d'acceptance fiables et lisibles en TypeScript

Talk #3 : Détecter les bugs depuis son IDE: TSDoc et autres recettes pratiques

Quand : 13 mai à partir de 19h

Où : Algolia 55 Rue d'Amsterdam · Paris

Détails : https://www.meetup.com/fr-FR/paris-typescript/events/307201552/

Les datacenters se multiplient. Le journal the Guardian explique que ces nouveaux sites s'installent dans des zones au risque l'eau manque ou en faiblesse hydrique. Or, avec le free cooling et le liquid cooling, l'eau est indispensable au refroidissement. Le journal anglais dit que les nouveaux projets sont nombreux dans les zones géographiques stressées : Arizona, Afrique du Sud, Golfe et Arabie, Espagne, Inde du nord, etc. 

La publication du Guardian s'appuie sur l'étude de SourceMaterial, une ONG. L'eau est un réel problème car plus le datacenter est grand et situé dans une zone où les températures sont élevées, plus il faut refroidir les infrastructures même si la température de fonctionnement est bien plus élevée qu'il y a 15 ans. 

Selon les données publiées par le journal anglais, plus de 270 nouveaux datacenters sont en projets ou en constructions. Cependant, il est dommage de parler uniquement d'Amazon, Microsoft et Google car de nombreux datacenters sont construits et opérés en dehors de ces fournisseurs. Il faut pondérer les données : les nouveaux datacenters dans les zones en déficit d'eau (actuel ou à venir) représentent actuellement environ 8 % des projets en développement et 10 % des sites en production. 

Plusieurs raisons expliquent ces constructions dans ces zones : les espaces disponibles, les avantages fiscaux et les facilités d'investissements ou encore l'ensoleillement. Ces sites bénéficient, notamment dans les Etats américains, d'autorisations d'usage de l'eau avec des quotas officiels. Pourquoi pas ne pas construire dans des zones tempérées où la température moyenne permettrait de réduire l'usage d'eau ? Les espaces disponibles sont moins nombreux et moins grands et la densité des datacenters y est parfois déjà élevé ainsi que la densité urbaine.

En parlant datacenter, où en sont les 35 nouveaux sites français promis en février dernier ?

Source : https://www.theguardian.com/environment/2025/apr/09/big-tech-datacentres-water?fbclid=IwY2xjawJkD7lleHRuA2FlbQIxMQABHtfHUpR1ulEZG-vNhSGtPXY3RFa4yvnYEgms4d6F4FPSDrMWzjamXUISwQyL_aem_VKoCv0afrY2-7feIZRJZtg

AWS Summit est l'événement annuel à Paris du géant du cloud. Sans surprise, AWS poursuit sa marche en avant sur l'IA. Les principales annonces :

- disponibilité du LLM Pixtral Large 25.02 de Mistral dans Bedrock

- Nova Sonic : un modèle d'IA pour créer des applications et agents vocaux

- Q Developer : accessible dans plusieurs langues

- Llama 4 est disponible sur AWS

Q Developer est l'outil d'AWS pour créer les documentations, les architectures, générer le code, etc. Le service supporte maintenant l'Anglais, le Chinois, l'Hindi et l'Espagnol. Toujours pas le Français par contre. Q Developer est disponible sur son IDE et les CLI. Sur Nova Sonic, c'est le nouveau modèle de la gamme Nova. Nova Sonic se dédie au speech-to-speech. Il cible les chats et le streaming. 

En poussant l'IA sur les services, AWS réaffirme en même temps son engagement en France pour promouvoir l'IA et la GenIA en général. Plus spécifiquement, AWS annonce un partenaire avec Safran pour innover en aéronautique et sur le spatial, grâce à l'IA. "La façon dont Safran adopte l'IA générative illustre parfaitement comment ces technologies avancées peuvent transformer l'industrie aéronautique," souligne Julien Groues, Directeur Général d'AWS France. "En combinant l'expertise métier de Safran avec la puissance du cloud et de l'IA d'AWS, nous ouvrons la voie à des innovations qui redéfiniront les standards de performance et de sécurité dans l'aviation." 

L'AWS Summit a été l'occasion de montrer le dynamisme de l'écosystème AWS que ce soit dans l'infrastructure, les bases de données ou encore les ESN et intégrateurs. Trois bémols : une partie purement développeur noyée dans la masse, l'absence du quantique qui est pourtant un des chantiers stratégiques et une partie green it / éco conception trop peu visible.  

Rider 2025.1 sera disponible très bientôt. La RC a été distribuée ce jour. Cette version supporte les préversions de .Net 10 et C# 14 ainsi que VB 17.13. Avec cette version, le développement distant sur un host Windows est disponible via JetBrains ToolBox App. On dispose aussi d'une nouvelle vue des fichiers dans l'explorateur de solution. On y gagne en clarté. Sur Roslyn, on peut explorer la structure du code C# comme l'arbre syntaxique en temps réel ou encore appliquer les suggestions de modification à travers les fichiers et les projets, en une unique étape. 

JetBrains continue à améliorer l'assistant IA : support des modèles GPT 4.5, Claude 3.7, Gemini 2. On peut aussi utiliser un modèle local (Ollama ou LM Studio). 

De nombreux nouveautés sont proposées : support du framework Noesis, mise à jour d'Unreal Engine, intégration d'Unity Profiler

Pour en savoir plus : https://blog.jetbrains.com/dotnet/2025/04/09/rider-2025-1-rc/

Profiler CPU Usage et Instrumentation supportent maintenant l'analyse multi-process dans une vue unique. Cela permet de voir l'activité CPU selon les différents processu en cours. On voit très rapidement l'activité avec des graphs permettant de visualiser les consommations et les ressources de chaque process. Cet exercice n'est pas toujours très facile. 

Désormais, on peut :

- avoir des graphiques distincts par couleur

- les détails de chaque process

- visualiser le process qui consomme le plus

- des filtres pour affiner l'affichage et les recherches de problèmes

- Identifiez plus rapidement les problèmes interprocessus grâce à une vue unifiée et simplifiée.

Post de l'équipe Visual Studio : https://devblogs.microsoft.com/visualstudio/multi-process-cpu-usage-analysis-in-visual-studio/

Voilà une bonne nouvelle : l'extension Genesis Code pour Visual Studio Code est disponible en version 1.5.2. Elle permet de coder "simplement" des jeux Sega Genesis (= Mega Drive) sur son éditeur favori. Genesis-code s'appuie sur SGDK/GENDEV ou MARSDEV. La configuration n'est pas forcément simple, notamment à cause des différentes variables d'environnement. 

L'extension permet de compiler et de builder les fichiers ROM, exécution le code via un émulateur, créer un nouveau projet, complétion de code, debug via GDB. 

Il faut installer un SDK Sega Genesis, configurer GDB et l'environnement. L'émulateur est directement acessible via l'extension. 

L'excellent SGDK est disponible en version 2.11. 

Site : https://marketplace.visualstudio.com/items?itemName=zerasul.genesis-code

Connaissez-vous le moteur d'animation anime.js ? Non ? C'est peut-être le bon moment pour le découvrir. La version 4.0.0 est disponible depuis quelques jours. Rien que les démos sont impressionnantes à voir : c'est rapide avec un rendu de haute qualité ! Il utilise les proprités CSS, SVG, les attributs DOM. L'installation est rapide et rapide : npm install animejs

anime.js se veut léger et totalement personnalisable tout en restant très polyvalent dans les usages. C'est assez bluffant. 

Il s'agit d'une version majeure : réécriture du projet, une nette amélioration des performances et de nombreuses nouveautés (times, animation, timeline, WAAP, SVG, etc.). Attention : la réécriture d'anime.js introduit aussi de nouveaux syntaxes et donc de la casse de codes.

Note de version : https://github.com/juliangarnier/anime/releases

A découvrir d'urgence : https://animejs.com/

Le projet JHipster passe en version 8.10.0. Cette évolution apporte plus de 455 pull requests et corrections. Les principales évolutions sont : Spring Boot 3.4.4, Gradle 8.13, Node 22.14.0, TypeScript 5.8.2. Un important travail de clean a été fait dans le code code ainsi que des corrections de bugs.

Cette version est dans la continuité des versions précédentes. A noter que l'environnement supporte Java 17, 21 et 24. 

Les principaux changements : https://github.com/jhipster/generator-jhipster/releases/tag/v8.10.0

WordPress 6.8 ne va pas tarder. La RC2 est disponible depuis quelques jours. Cette version ne doit pas être mise en production. Pas d'évolution depuis la liste des changements de la bêta 1. Cependant, l'équipe WordPress met en avant : le chargement spéculatif, le bcrypt pour le hashage des mots de passe, les améliorations sur les évolutions UI. 

La version finale de la 6.8 est attendue pour le 15 avril. 

Note de version de la bêta 1 : https://wordpress.org/news/2025/03/wordpress-6-8-beta-1/

Annonce RC2 : https://wordpress.org/news/2025/04/wordpress-6-8-release-candidate-2/

PhyX est un puissant framework / SDK pour la modélisation et la simulation en prenant en compte la physique des éléments. Il permet de reproduire la physique d'un objet, d'un système, d'un élément. Ces simulations exigent de la puissance de calculs et une implémentation profonde de la physique réel. NVIDIA cible les usages dans la robotique et les systèmes autonomes.

PhysX est disponible sur GitHub. En plus de PhysX, le SDK inclut : Flow et Blast. FLow est une librairie dédiée aux fluides. Blast est une librairie de GameWorks destruction qui remplace le module APEX Destruction. A noter que l'accélération GPU est incluse dans cette ouverture. 

Portail officiel : https://developer.nvidia.com/physx-sdk

Le navigateur est un point d'accès pour les hackers, les virus, les portes dérobées, etc. VirtualBrowser protège le navigateur en isolant les accès web. L'éditeur appelle cela le Remote Browser Isolation. En fait, la navigation sur les sites est envoyée sur un environnement isolé distant et notre navigateur ne reçoit que l'affichage (le rendu pixel). "Contrairement aux solutions de filtrage web traditionnelles qui se limitent à autoriser ou bloquer l’accès à des sites, VirtualBrowser protège l’utilisateur et son poste de travail de toute exécution de code malveillant en déportant physiquement l’exécution de la navigation internet sur un serveur distant." précise l'éditeur. 

L'outil met en avant :

- rendu rapide

- protection proactive

- "lecteur seule"

On peut interdire tout accès aux sites non référencés, ajuster les politiques d'accès. La solution peut être en mode SaaS. Dans ce cas, OOdrive s'occupe de tout, soit vous exécutez sur vos serveurs. 

Comment ça fonctionne ? "Depuis une simple URL, VirtualBrowser permet d’accéder à vos applications sensibles (SaaS ou sur site) via une session de navigation jetable sécurisée accessible depuis n’importe quel terminal, même non maîtrisé (BYOD, sous-traitants). Sans modifier l'infrastructure, le web application isolation de VirtualBrowser protège vos données sensibles en isolant la navigation et en contrôlant les interactions permises aux utilisateurs. Cela évite toute exposition à des menaces externes ou des violations de données, tout en simplifiant l'accès sécurisé depuis des appareils distants (ZeroTrust)." précise VirtualBrowser.

Il peut remplacer un VPN. 

Site : https://www.virtualbrowser.com/

NumSpot dévoile des services concrets et opérationnels. Ce sont les premières briques de son offre cloud public. Les entreprises et le secteur public sont les premières cibles de NumSpot. 

Le scaleur propose en cloud public  :

• Kubernetes : Système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées.
• OpenShift : Orchestrateur de conteneurs, OpenShift automatise le déploiement, la gestion et la mise à l'échelle des applications conteneurisées en veillant à ce que les applications soient hautement disponibles et facilement évolutives. Le service managé OpenShift proposé par NumSpot respecte les pratiques les plus exigeantes pour garantir un espace dédié et cloisonné.
• Base de données PostgreSQL : Moteur de base de données relationnelles et objet open source, réputé pour sa robustesse et ses performances.

L'objectif est d'être certifié SecNumCloud. "“NumSpot, acteur 100% européen, apporte aujourd’hui avec sa plateforme de services une alternative au marché en matière de cloud public. Les entreprises et les administrations souhaitant avoir la certitude de pouvoir conserver le contrôle de leurs données et garder l’agilité du cloud pour accélérer leur transformation numérique ont désormais une solution pérenne à leur disposition. La plateforme NumSpot propose un portefeuille de solutions Cloud avec une expérience utilisateur intégrée incluant les services d’infrastructure d’Outscale (filiale de son actionnaire Dassault Systèmes). Aujourd’hui, il s’agit d’une première étape, notre plateforme va être amenée à s’enrichir rapidement et régulièrement avec des nouveaux services répondant aux enjeux stratégiques de nos clients”. explique Eric Haddad, le président de NumSpot. 

Aujourd'hui, NumSpot propose des services de gestions, du compute, du conteneur, du réseau, du stockage, de la base de données et de la sécurité et identifié. Une partie de ces services est disponible. D'autres sont en cours de développement. La partie développeur n'est pas disponible et se réduit à des blueprints et au CI/CD.  

Site : https://numspot.com/