Raspberry Pi annonce la disponibilité de la nouvelle version de son OS basée sur Debian. Actuellement, Raspberry Pi OS repose sur Debian bookworm. La prochaine sera sur Debian trixie. 

Les nouveautés les plus importantes :

- écran de verrouillage a été modifié : on peut verrouiller l'écran en faisant Contrôle - Alt - L. 

- auto login : disponible séparement sur la console et le desktop. Voir panneau de configuration

- l'application Imprimantes est entièrement refaite en utilisant le plugin imprimante de Gnome et en la transformant en application autonome. On peut y accéder depuis la section préférence du menu

- les écrans tactiles devraient mieux être pris en charge par cette version. Cette gestion est assez nouvelle dans Wayland

- utilisation de labwc 0.8.1 pour Wayland

Pour mettre à jour :

sudo apt update

sudo apt full-upgrade

Le gouvernement fédéral américain poursuit les coupes dans les budgets des agences officielles. C'est au tour de l'agence de la sécurité des infrastructures et de la cybersécurité d'être confrontée aux menaces et aux coupes budgétaires. La CISA pourrait perdre 491 millions $.

La CISA est accusé par Trump de contribuer à la censure et d'abandonner sa mission première. La menace est pour le moment de pure forme car le congrès américain doit valider cette réduction qui représente 17 % du budget de fonctionnement de l'agence. Un des reproches concerne la sécurité des élections et le président évoque les résultats de 2020 et la victoire de Biden. La maison blanche veut que la CISA se recentre sur les missions premières et qu'elle se préoccupe plus de censurer que de protéger les intérêts du pays. 

La CISA emploie 3 600 personnes et possède un budget de 3 milliards $. 

Piper est un système open source pour faire du text to speech localement, un TTS pour résumer. Avec une simple Raspberry Pi, on peut faire du TTS. Il supporte de nombreuses voix localisées (Allemand, Anglais, Français, Italien, etc.). Il suffit de charger le modèle voulu et de la configurer. La langue se compose de deux fichiers : .onnx (modèle proprement dit) et .onnx.json (configuration).

Il fonctionne avec les Pi 32 et 64 bits. On l'utilise avec Python :

pip install pip-tts

Les usages sont nombreux : assistant vocal, fonctionnalité d'accessibilité, etc. On le retrouve dans le projet Rhasspy.

GitHub du projet : https://github.com/rhasspy/piper?tab=readme-ov-file

Le magazine Programmez! ouvre l'appel à sessions (CFP) pour la conférence informatique quantique du 9 octobre 2025 à l'école 42 (Paris). 

Les thèmes abordés :

- hardware et les principes de l'ordinateur quantique

- usages

- modèles de développement (langages, SDK, etc.)

- overview du quantique

Thème ouvert à proposition. 

Luc Julia, bien connu dans le monde technologique et co-créateur de Siri, n'a jamais été tendre avec l'IA et son développement. Il rappelle que l'IA n'est pas intelligence, du moins, pas dans le sens humain du terme. Son dernier livre revient que la notion d'IA et les (fausses) promesses autour de ces technologies. 

Il démonte les promesses des IA, de la GenIA et qu'elles ne sont pas créatives, ni sans limite. Elles reposent sur des données bien réelles et répondent à nos requêtes. 

L'ouvrage est disponible le 7 mai aux éditions Le cherche midi.

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.