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