La mise à jour de mars du Pixel dévoile une importante nouveauté dans les options de développemenet : la possibilité d'installer et d'utiliser un terminal Linux natif directement sur son Pixel Android ! L'environnement est basé sur une Debian. Le terminal s'exécute dans un environnement virtuel AVF (Android Virtualization Framework). Pour les développeuers, cette annonce est particulièrement intéressante car cela laisse présager la possibilité de créer des apps Linux pour Android. 

Pour le moment, Google n'a pas précisé l'objectif de ce Linux Terminal sur Android. Il peut aussi s'agit d'un test auprès des développeurs pour voir les usages et avoir des retours. Rappelons qu'il s'agit d'une option pour les développeurs et rien ne dit que le terminal Linux sera gardé. 

Est-ce un changement de paradigme pour Android ? Nous le saurons dans les prochains mois. 

Début décembre 2024, Microsoft Threat Intelligence détecte une vaste campagne de malware qui impacte plus d'un million de terminaux. Le malware avait pour rôle de voler des informations des utilisateurs. L'attaque venait de sites de streaming embarqués illégaux avec de multiples redirections avec l'utilisateur de comptes GitHub. Les dépôts GitHub utilisés par l'attaque ont été fermés. Ces comptes permettaient de déployer sur les postes des fichiers et des scripts. 

"Les fichiers ont été utilisés pour collecter des informations système et pour mettre en place d'autres programmes malveillants et scripts pour exfiltrer des documents et des données de l'hôte compromis. Cette activité est suivie sous le nom générique Storm-0408 que nous utilisons pour traquer de nombreux acteurs de la menace associés à l'accès à distance ou aux programmes malveillants de vol d'informations et qui utilisent le phishing, l'optimisation des moteurs de recherche (SEO) ou les campagnes de malvertising pour distribuer des charges utiles malveillantes." précise l'équipe Microsoft. 

Visiblement, l'attaque s'est faite en 3 grandes étapes :

- étape 1 : déploiement du malware d'origine qui servait à charger les scripts complémentaires sur le poste compromis

- étape 2 : les fichiers et scripts découvrent le système, récupère les informations et les envoient à d'autres sites en utilisant un encodage Bas64 dans l'URL. The information collected included data on memory size, graphic details, screen resolution, operating system (OS), and user paths.

- étape 3 : activité malveillante supplémentaire envoyée par le malware 

Analyse très complète : https://www.microsoft.com/en-us/security/blog/2025/03/06/malvertising-campaign-leads-to-info-stealers-hosted-on-github/

La prochaine WWDC d'Apple se tiendra au mois de juin. Des rumeurs parlent des prochaines versions d'iOS, macOS et iPadOS. Généralement bien informé, Mark Gurman évoque une profonde refonte de l'interface des principaux OS de la Pomme. Il s'agirait de faire converger les grandes tendances graphiques des OS pour aboutir à une approche commune. La dernière refonte de l'UI d'iOS remonte à 2013, celle de macOS à 2020. Et depuis, les UI ont évolué sans harmonie globale entre les plateformes. 

Au départ, l'interface Aqua de MacOS X avait été la base d'iOS avant qu'iOS n'influence macOS en 2020. Gurman évoque même que l'UI de Vision Pro serait à l'origine de ce vaste chantier qui a sans aucun doute débuté il y a plusieurs mois. Gurman s'étonne d'une possible influence de Vision OS sur les autres OS du constructeur car généralement, Apple cherche à rassurer les utilisateurs avec une approche connue. Est-ce là un moyen pour Apple de rendre plus "commun" l'UI du Vision Pro.

Cette possible refonte majeure de l'UI ne cache pas les retards d'Apple Intelligence et le nouveau Siri ne sera pas disponible avant 2026, soit plus d'un an de retard sur les annonces de la WWDC 2024. 

Réponse dans 3 mois à la WWDC. 

Microsoft annonce que son outil Publisher ne sera plus pris en charge après octobre 2026. "En octobre 2026, Microsoft Publisher atteindra sa fin de vie. Après ce délai, il ne sera plus inclus dans Microsoft 365 et les suites locales existantes ne seront plus prises en charge. Les abonnés Microsoft 365 ne pourront plus ouvrir ou modifier les fichiers publisher dans Publisher. D’ici là, la prise en charge de Publisher continuera et les utilisateurs peuvent s’attendre à la même expérience qu’aujourd’hui. " indique l'éditeur. 

Publisher s'utilise pour créer des étiquettes, des bulletins, des cartes, etc. Microsoft préconise d'utiliser Word, PowerPoint et Designer pour remplacer Publisher. 

 Durant la conférence ElasticON 2025 à Paris, nous avons rencontré David Pilato (Developer Advocate, Elastic) et Fabien Baligand (CDC Informatique) pour parler IA, de logs et du rôle de la communauté sur Elastic.

François Tonic : comment des plateformes comme celles d’Elastic peuvent aider la CDC au quotidien ?

Fabien : Nous avons de nombreux cas d’usage. Nous avons commencé en 2013 par l’analyse de logs. Cela a beaucoup aidé nos équipes en production pour le monitoring et ensuite pour le search sur les applications métiers afin d’effectuer de la recherche en full text. Nous commençons à regarder tout ce qui concerne l’IA, à la fois côté AIOps pour l’observabilité et aussi dans le domaine de la recherche sémantique ou de la sémantique hybride sur les documentations et les contenus métiers.

On connaît Elastic pour le Search, mais aujourd’hui c’est bien plus large que ça ?

David : Aujourd’hui, tout est une question de recherche. On peut appliquer la recherche à de nombreux domaines comme les données d’observabilité, les données de sécurité, les données métiers ou même à la BI.  Et l’arrivée de l’IA redonne de l’intérêt à la barre de recherche qui avait été un peu délaissée.

Quelle était la problématique de départ pour utiliser les outils Elastic ?

Fabien : Quand on a commencé, on n’avait pas de visibilité sur ce qui se passait sur le banc de test ou sur la production. On manquait de visibilité fine. On avait quelques outils mais ils étaient trop macroscopiques. Il manquait quelque chose de plus avancé. L’analyse de logs nous a permis, en combinaison avec Kibana et Elasticsearch, d’avoir des données très précises sur ce qu’il se passait exactement dans les applications et de savoir où se trouvaient les problèmes, les goulets d’étranglement, etc. Cela nous a beaucoup aidé pour les tests de performance avant de passer en production et cela nous a permis de régler de nombreux problèmes. 

David : Tu n’avais pas un problème sur la mise en cohérence des événements ?

Fabien : Effectivement, à l'époque, je voulais pouvoir agréger des données provenant de plusieurs logs pour finalement les mettre dans un seul événement. J’ai développé un plug-in : logstash-filter-aggregate. J’en ai parlé à David. Il m’a donné les contacts pour pouvoir intégrer le plug-in dans Logstash. Et plus tard, j’ai présenté le plug-in lors d’un meetup Elastic.

David : Fabien est non seulement un utilisateur, mais il a aussi contribué à la plateforme pour résoudre ses problèmes et mettre sa création à disposition de toute la communauté.

Tu avais donc des logs plus ou moins éclatés. Il fallait pouvoir les centraliser pour avoir une vue plus claire et en sortir les bonnes informations ?

Fabien : L’idée était de récupérer les logs, de les parser pour créer des logs structurés, puis de les remonter dans les tableaux de bord Kibana. Cela nous permettait d’afficher des données précises, comme les transactions et les appels aux web services. On voyait tout ce qui se passait en termes de temps d'exécution et de charge, avec un niveau de détail très fin au niveau de l'application.

À l’époque, APM n’existait pas encore, donc nous utilisions Log Analytics. Quand APM est arrivé, l’outil a permis de gérer cela nativement, sans avoir besoin de développer des logs spécifiques. Aujourd’hui, on utilise beaucoup APM, et ça fonctionne automatiquement. Toutes les données remontent, et les tableaux de bord sont prêts à l’emploi. Nous avons plusieurs centaines de services qui l’exploitent.

Comment aujourd’hui, les équipes trouvent les bons logs : des batteries de règles, analyses, de l’IA ?

Fabien : C’est un mélange de tout cela. On écrit beaucoup de logs au format ECS. De base, les logs sont structurés et couplés avec APM, ce qui permet de croiser les traces APM avec les logs ECS. Comme les applications disposent d’ID de requête uniques, on peut corréler les logs et les traces grâce à ces ID et identifier rapidement quelles applications sont concernées.

J’ai vu des tests sur Swagger : en récupérant l’ID, les résultats génèrent un lien qui permet, en un clic, d’afficher les traces de ce qu’il s’est passé. C’est une super idée. On fait beaucoup de recherches basées sur les ID.

Une autre fonctionnalité pratique dans APM, c’est la visualisation des erreurs, avec pour chaque message d’erreur, le nombre d’occurrences. Pour les équipes, c’est important, car elles peuvent repérer facilement les erreurs fréquentes, les analyser et les traiter en priorité. On définit ainsi la priorité des erreurs en fonction de leur fréquence d’apparition.

J’essaie de donner tous les outils nécessaires aux développeurs et aux Ops. L’idée est qu’ils soient autonomes sur de nombreux usages. J’ai vu des équipes réaliser des tableaux de bord très complets sur leurs domaines, sans que j’ai besoin d’intervenir.

Chaque projet dispose de son propre espace Kibana, et les équipes ont une totale autonomie pour créer des visualisations, des recherches, des tableaux de bord, etc. Cela leur permet d’adapter leur espace à leurs besoins spécifiques.

Est-ce que tu as eu besoin de faire des formations, une montée en compétence ?

Fabien : Il y a une équipe dédiée au socle technique, à laquelle je participe. Ensuite, nous proposons des formations et mettons à disposition une documentation complète. La plupart des équipes sont autonomes dans leur utilisation. Je reçois beaucoup de retours et, de temps en temps, certaines équipes me demandent de l’aide, mais dans l’ensemble, elles sont vraiment autonomes. 

Tu nous parlais de l’aspect communautaire. Peux-tu nous en dire plus ? Ton plug-in est intégré à la plateforme ?

David : Avant même la création de l’entreprise, Elastic était un projet open source. L’outil l’est resté, et la société n’a été fondée que deux ans après la première release. Très vite, une communauté s’est formée. J’ai d’ailleurs créé la communauté française, qui n’existait pas encore à l’époque. Au fil du temps, la communauté a enrichi la solution en y ajoutant de nouvelles fonctionnalités, comme l’a fait Fabien.

Fabien : À l’origine, le plug-in que j’ai créé était un plug-in communautaire, que j’ai partagé sur le dépôt GitHub. Il a rencontré un tel succès qu’Elastic a décidé de l’intégrer directement dans le projet Logstash. C’est une petite fierté pour moi ! Dès que je peux “open-sourcer” un travail, j’aime le faire. Depuis, j’ai pu apporter d’autres contributions aux produits Logstash, Kibana et Elasticsearch, mais aussi créer d’autres plugins communautaires autour de la stack Elastic. J’ai même conçu une page web qui affiche tous les champs ECS sur une seule page avec une barre de recherche ! Sur la documentation officielle, ils sont répartis sur 20 pages…