À peine dévoilé, le nouveau Tesla Model Y Performance se montre déjà en public. Nous sommes allés le découvrir dans une concession à Paris et voici nos impressions.
Le courant AMOC qui traverse l'Océan Atlantique est vital pour la planète. Pourtant, de plus en plus d'indices le voient ralentir sous l'effet du réchauffement climatique, ce qui fait craindre un effondrement, fatal pour l'écosystème.
Battlefield 6 arrive à la rentrée et, après les phases de bêta d’août, DICE a finalement révélé les configurations PC définitives. Les profils minimale et recommandée restent inchangés, mais une nouvelle catégorie "Ultra" vient s’ajouter.
Le vol de cuivre ne touche plus seulement les chantiers et le rail. Les bornes de recharge deviennent à leur tour la cible de réseaux organisés, privant brutalement les électromobilistes d’accès à l’énergie.
Vous cherchez le film idéal pour rire aux éclats et vous détendre le temps d'une soirée canapé ? Vous êtes au bon endroit : voici notre sélection des 10 meilleures comédies à découvrir sur Netflix.
Le 9 septembre, Apple organise une keynote dédiée à la présentation des iPhone 17. La marque américaine devrait en profiter pour dévoiler la date de sortie d'iOS 26, sa grande mise à jour de l'iPhone avec un nouveau design : le Liquid Glass.
[Deal du jour] TCL fait partie des marques qui ont le plus contribué à démocratiser le Mini-LED. Tous les modèles ne coûtent pas une fortune, comme ce grand TV 55" actuellement en promotion.
La société américaine Anthropic dévoile une campagne de vols de données orchestrée à l’aide de son modèle de génération de code Claude Code. En un mois, l'opération aurait mis en danger 17 organisations. Le mode opératoire repose sur ce qu’Anthropic désigne comme du vibe hacking.
Pour célébrer un record d'utilisation atteint avec la fusée Falcon 9, la patronne de SpaceX a partagé une vidéo faisant office de bêtisier : on y voir certains des pires crashs du lanceur, lorsqu'il tentait d'atterrir.
[Deal du jour] La Pixel Watch est une montre connectée qui rivalise directement avec l’Apple Watch et autre Samsung Galaxy Watch. Google vient tout juste de lancer sa quatrième génération, ce qui entraîne logiquement une baisse de prix intéressante pour la génération précédente.
Cet article a été réalisé en collaboration avec Fortuneo
Certains évènements comme le nouvel accord entre l’Europe et les États-Unis sur les taxes douanières peuvent constituer de belles opportunités pour les investisseurs. Si vous êtes prêt à diversifier votre épargne, Fortuneo dispose d’une offre complète et abordable.
Cet article a été réalisé en collaboration avec Fortuneo
Il s’agit d’un contenu créé par des rédacteurs indépendants au sein de l’entité Humanoid xp. L’équipe éditoriale de Numerama n’a pas participé à sa création. Nous nous engageons auprès de nos lecteurs pour que ces contenus soient intéressants, qualitatifs et correspondent à leurs intérêts.
Ça va, elle vous plait toujours ma série de l’été ? Je suis loin d’avoir fini mais on fera une petite pause bientôt. Toutefois, rassurez-vous, j’en ai encore sous le pied. La preuve avec cette nouvelle histoire d’un ver informatique qui a foutu le bordel sur Internet en juillet 2001.
Code Red. Un nom qui fait encore trembler les admins système qui l’ont vécu. Des centaines de milliers de serveurs infectés en quelques heures, des milliards de dégâts, et la Maison Blanche obligée de changer l’adresse IP de son site web pour éviter une attaque DDoS massive.
Et tout ça, découvert par deux hackers qui buvaient du Mountain Dew Code Red dans leur bureau de Californie un vendredi soir. Mais le plus dingue dans cette histoire, c’est surtout que la vulnérabilité exploitée avait été découverte un mois plus tôt.
Microsoft avait même publié le patch MS01-033, mais personne ne l’avait installé. Du coup, le 19 juillet 2001, Internet a découvert ce que pouvait faire un ver capable de se propager automatiquement sans intervention humaine….
Voici donc l’histoire complète de Code Red, depuis la découverte de la faille jusqu’à la panique mondiale.
L’histoire commence avec Riley Hassell, qui travaille chez eEye Digital Security à Aliso Viejo en Californie. En juin 2001, ce chercheur en sécurité passe ses soirées à chercher des vulnérabilités dans les logiciels populaires. Pas pour faire le mal, juste pour le défi, pour la gloire dans la communauté underground. Riley fait partie de cette génération de hackers qui considère que trouver des failles est un sport intellectuel.
Un soir, Riley s’attaque à IIS (Internet Information Services), le serveur web de Microsoft. IIS propulse des millions de sites web dans le monde, des petites entreprises aux gouvernements et si vous trouvez une faille dedans, c’est le jackpot. Riley commence donc à fuzzer l’ISAPI (Internet Server Application Programming Interface) d’IIS, envoyant des requêtes malformées pour voir comment le serveur réagit. Il faut savoir qu’à l’époque, IIS 5.0, intégré à Windows 2000, était devenu une cible de choix avec ses nouvelles fonctionnalités WebDAV et ses méthodes d’authentification avancées.
Et là, bingo. Riley découvre que si vous envoyez une requête GET avec une URL super longue au fichier idq.dll (utilisé par l’Indexing Service d’IIS), le serveur plante. Mieux encore, avec la bonne séquence de caractères, vous pouvez exécuter du code arbitraire sur le serveur. C’est ce qu’on appelle un buffer overflow, le Saint Graal des vulnérabilités. Plus précisément, la faille se trouve dans la façon dont idq.dll gère les requêtes puisque le filtre ISAPI .ida (indexing service) ne vérifie pas correctement les limites de ses buffers d’entrée.
Riley et l’équipe d’eEye publient leur découverte le 18 juin 2001. Microsoft réagit immédiatement en publiant le bulletin de sécurité MS01-033 et un patch. L’alerte est claire, cette vulnérabilité est critique car elle permet de prendre le contrôle total d’un serveur IIS avec des privilèges SYSTEM. Le bulletin précise aussi que la vulnérabilité affecte IIS 4.0 sur Windows NT 4.0 et IIS 5.0 sur Windows 2000.
Sauf que voilà, personne n’installe ce patch. C’est dramatique, mais les admins système sont débordés, les entreprises ont peur de “casser” leurs applications, et puis bon, qui va vraiment exploiter cette faille ? Un mois passe et les serveurs restent vulnérables…
Les premiers signes d’alerte apparaissent finalement le 12 juillet 2001. Ken Eichman, ingénieur sécurité senior chez Chemical Abstract Services, remarque quelque chose d’étrange dans ses logs. Trois tentatives d’accès illégales depuis une seule adresse IP, apparemment en provenance de l’Université de Foshan en Chine. Et le lendemain, le 13 juillet, c’est l’escalade : 611 attaques depuis 27 serveurs différents. Eichman, contributeur régulier de DShield.org, alerte alors Johannes Ullrich. Le samedi 14 juillet, les sources d’attaque dépassent les 1 000. Le lundi 16 juillet, la confirmation tombe : c’est un ver.
A l’époque, les experts pensent à des scans de routine, donc rien d’alarmant. Mais ils ont tort car le ver est programmé pour rester relativement dormant jusqu’au 19 juillet inclus. C’est donc une énorme bombe à retardement.
Car quelque part dans le monde, un ou plusieurs programmeurs anonymes ont en réalité créé quelque chose de dangereusement nouveau… Ils ont pris la vulnérabilité découverte par Riley et codé le premier véritable ver informatique à propagation automatique. Pas besoin d’envoyer des emails, pas besoin d’interaction humaine. Le ver scanne Internet, trouve les serveurs IIS vulnérables, les infecte, et utilise ces nouveaux zombies pour scanner encore plus vite. Le code, écrit en assembleur Win32 Intel, ne fait que quelques milliers d’octets… C’est une œuvre d’art malveillante en miniature.
Le ver exploite astucieusement l’absence d’ASLR (Address Space Layout Randomisation) et de DEP (Data Execution Prevention) dans Windows 2001. Les DLLs se chargent toujours aux mêmes adresses sur tous les systèmes. Comme ça, le ver sait que l’adresse mémoire 0x7801CBD3 pointera vers MSVCRT.DLL, qui est la bibliothèque Microsoft Visual C Runtime. À cette adresse précise, il trouve l’instruction machine CALL [EBX], et ce registre EBX contient une adresse sur la pile modifiée par le fameux buffer overflow. Du coup le CPU exécute directement le code du ver. C’est du génie maléfique !
Dans les bureaux d’eEye Digital Security en Californie, Marc Maiffret et Ryan Permeh travaillent tard ce jeudi 19 juillet. Maiffret, qui n’a que 20 ans, est déjà une légende dans le milieu. Ancien hacker sous le pseudo “Chameleon”, il a fondé eEye à 17 ans après une visite du FBI chez lui. Ironie du sort, quelques semaines après cette visite, il s’associait avec Firas Bushnaq pour créer la société. Ryan Permeh, son collègue et ami, est quant à lui surnommé “Overflow Ninja” pour son expertise en reverse engineering.
Marc Maiffret (à gauche), Ryan Permeh (au milieu) et Riley Hassel (à droite) - source
Vers 20 heures, leurs systèmes de détection s’affolent. Un truc bizarre se passe sur Internet. Des milliers de serveurs IIS tentent de se connecter à d’autres serveurs avec des requêtes étranges contenant “/default.ida?” suivi d’une longue chaîne de caractères de ‘N’ et de shellcode encodé. Maiffret et Permeh commencent alors à analyser le trafic. Et ce qu’ils découvrent les glace.
C’est un ver qui exploite la vulnérabilité MS01-033 découverte par leur collègue Riley Hassell. Mais contrairement aux virus classiques, ce ver n’a pas besoin d’intervention humaine. Il scanne les adresses IP de manière pseudo-aléatoire avec une seed fixe, cherchant le port 80 (HTTP). Quand il trouve un serveur IIS non patché, il envoie sa charge utile et prend le contrôle du serveur.
Une fois installé, le ver fait plusieurs choses. D’abord, sur les systèmes en anglais, il défigure le site web en affichant un message : “HELLO! Welcome to http://www.worm.com ! Hacked By Chinese!” Un message provocateur qui fait immédiatement penser à une attaque chinoise.
En effet, le contexte géopolitique est tendu car trois mois plus tôt, le 1er avril 2001, un avion espion américain EP-3 et un chasseur chinois J-8 sont entrés en collision au-dessus de la mer de Chine méridionale. Le pilote chinois Wang Wei est mort, et l’équipage américain a été détenu pendant 11 jours. S’en est suivie une cyber-guerre entre hackers patriotes des deux pays. Ainsi, la Honker Union chinoise et des groupes américains se sont affrontés, défaçant des centaines de sites.
Maiffret et Permeh réalisent l’ampleur de la catastrophe. Ils ont besoin d’un nom de code pour l’incident. Sur le bureau, une canette de Mountain Dew Code Red, la nouvelle boisson caféinée rouge cerise lancée quelques semaines plus tôt. “Code Red”, dit-il. Le nom est parfait car c’est une alerte rouge pour Internet.
Mais ce n’est que la partie visible de l’iceberg. Le ver installe aussi une backdoor, désactive le service d’indexation d’IIS pour éviter les plantages, et surtout, il contient une bombe logique car à partir du 20 juillet, et jusqu’au 28 de chaque mois, tous les serveurs infectés lanceront une attaque DDoS coordonnée contre l’IP 198.137.240.91. C’est celle de www.whitehouse.gov . Des centaines de milliers de serveurs zombies s’apprêtent à bombarder simultanément le site du président américain. C’est de la cyberguerre, ni plus ni moins, cependant, le ver a une faiblesse : il cible une IP hardcodée, et pas le nom de domaine.
Les deux chercheurs passent la nuit à analyser le ver. Le code est relativement simple mais très efficace. Avec ses 100 threads simultanés pour scanner Internet, chaque serveur infecté devient un nouveau point de départ pour l’infection. C’est de la croissance exponentielle pure. Le ver cherche d’abord kernel32.dll en mémoire, scannant la plage 77E00000h–78000000h par incréments de 64K à la recherche de la signature ‘MZ’. S’il ne trouve rien, il essaie à partir de 0BFF00000h, supposant qu’il tourne peut-être sur Windows 9x plutôt que NT.
Le plus brillant dans le code, c’est la méthode de génération des adresses IP. Grâce à un générateur pseudo-aléatoire avec une seed fixe basée sur la date, tous les vers scannent les mêmes adresses dans le même ordre, évitant ainsi de saturer inutilement les mêmes cibles. C’est de l’optimisation de haute volée. Si SP1 ou SP2 est installé sur la machine, ou si elle tourne sous Windows NT 4.0, le ver ne peut pas se propager et le service WWW Publishing d’IIS plante simplement.
Au matin du 19 juillet, eEye publie une alerte d’urgence. Mais c’est déjà trop tard. Le ver se propage à une vitesse folle. À midi, plus de 100 000 serveurs sont infectés. David Moore et Colleen Shannon du CAIDA (Cooperative Association for Internet Data Analysis) à l’UC San Diego observent des chiffres hallucinants : en 14 heures, Code Red infecte 359 000 serveurs. Le pic d’infection atteint plus de 2 000 nouveaux hôtes par minute. Les réseaux commencent à saturer sous le trafic de scan.
Les CERT (Computer Emergency Response Team) publient l’Advisory CA-2001-19 à 14h00 et Microsoft republie en urgence son patch avec des avertissements en gros caractères. Les FAI commencent à bloquer le trafic suspect mais le ver est déjà partout. Le FBI et le NIPC (National Infrastructure Protection Center) lancent une enquête.
La communauté de la sécurité informatique est en ébullition. Sur Bugtraq, SecurityFocus, et les mailing lists, les experts échangent frénétiquement des informations. Comment stopper le ver ? Comment protéger les serveurs ? Comment éviter l’attaque DDoS contre la Maison Blanche prévue pour le lendemain ?
Car c’est ça le vrai danger. Si des centaines de milliers de serveurs attaquent simultanément whitehouse.gov, non seulement le site tombera, mais les dégâts collatéraux seront énormes. Les routeurs Internet pourraient saturer, les DNS pourraient flancher. C’est potentiellement Internet tout entier qui pourrait être affecté. 43% des serveurs infectés sont aux États-Unis, 11% en Corée, 5% en Chine, 4% à Taiwan.
La Maison Blanche prend la menace au sérieux. Une réunion de crise est organisée avec Akamai Technologies, qui héberge le site. La décision est radicale : Il faut changer l’adresse IP de whitehouse.gov. Si le ver attaque l’ancienne IP hardcodée, il ne touchera qu’une adresse vide.
Le 19 juillet au soir, Akamai procède au changement d’IP en urgence. L’opération est délicate : il faut propager la nouvelle adresse dans tous les serveurs DNS du monde. Normalement, ça prend 24 à 48 heures. Ils n’ont que quelques heures….
Les dégâts sont considérables car des milliers de sites web affichent “Hacked by Chinese!” au lieu de leur contenu normal. Des entreprises perdent des millions en revenus. Les équipes IT travaillent jour et nuit pour patcher et nettoyer les serveurs. Le coût total sera estimé à 2,6 milliards de dollars par Computer Economics : 1,1 milliard en coûts de nettoyage et 1,5 milliard en perte de productivité.
Mais le pire est évité. Le 20 juillet à 20h00, quand les serveurs infectés lancent leur attaque DDoS, ils bombardent l’ancienne IP de whitehouse.gov. Et rien. Ouf, la Maison Blanche a réussi son pari. Le stratagème a fonctionné parfaitement.
De plus, le ver Code Red original a une particularité : il ne survit pas au redémarrage. Il persiste uniquement en mémoire vive. Redémarrez le serveur, et il disparaît. Mais si vous ne patchez pas, il sera réinfecté en quelques minutes par un autre serveur zombie. C’est Sisyphe version numérique. Le ver est d’ailleurs programmé pour arrêter de scanner après minuit UTC et reprendre son activité le 1er et le 19 de chaque mois.
Et le 31 juillet, sans surprise, le ver se réactive comme prévu provoquant une nouvelle vague d’infections, et un nouveau chaos. Cette fois, les admins sont mieux préparés, mais les dégâts restent importants. Le CERT publie l’Advisory CA-2001-23 “Continued Threat of the Code Red Worm”.
Et puis, le 4 août 2001, c’est l’escalade. Une nouvelle variante apparaît : Code Red II. Malgré son nom, c’est un ver complètement différent, écrit par d’autres auteurs qui ont juste inclus la chaîne “CodeRedII” dans leur code. Au lieu de défigurer les sites, il installe une backdoor permanente qui survit aux redémarrages.
Code Red II modifie le système pour permettre l’exécution de commandes à distance. Il copie cmd.exe (l’invite de commandes Windows) dans les répertoires web comme “scripts” et “msadc”. N’importe qui peut maintenant exécuter des commandes sur les serveurs infectés via une simple URL. C’est la porte ouverte au pillage de données. Le ver installe aussi un rootkit appelé “Virtual Root” et n’a pas de fonction DDoS mais cherche à infecter les systèmes proches géographiquement.
Code Red II a été programmé pour se propager plus agressivement en Chine. Si le système infecté est configuré en chinois, le ver lance alors 600 threads de scan au lieu de 300. C’est drôle, vu le message “Hacked by Chinese!” de la première version. Le ver s’arrête de fonctionner après le 1er octobre 2001.
Bien sûr la communauté chinoise proteste contre l’amalgame créé par le message et le gouvernement chinois dément toute implication. Les experts en sécurité sont également sceptiques car le message semble être une diversion. eEye pense que le ver vient de Makati City aux Philippines, le même endroit d’où venait le ver VBS LoveLetter .
En réalité, l’origine de Code Red reste encore aujourd’hui mystérieuse car contrairement à ILOVEYOU (de Onel de Guzman aux Philippines) ou Solar Sunrise (deux ados californiens), aucun auteur n’a jamais été identifié. Les théories abondent bien sûr. Certains pensent que ce seraient des hackers chinois de la Honker Union, d’autres un groupe criminel russe, ou un script kiddie américain provocateur, ou encore un false flag d’une agence de renseignement… Le mystère reste entier…
Ce qui est sûr, c’est que Code Red a fait découvrir au monde la puissance des vers à propagation automatique. Plus besoin de social engineering, plus besoin que des utilisateurs cliquent sur des pièces jointes. Un ver se propage maintenant tout seul, exploitant la négligence des admins.
Grâce à sa découverte, Marc Maiffret devient une célébrité du jour au lendemain. Ce jeune de 20 ans qui a baptisé Code Red est invité sur CNN, interrogé par le FBI, consulté par le Congrès américain…etc. Ryan Permeh, plus discret mais tout aussi brillant, continue à l’époque son travail de reverse engineering et dans les mois qui suivent, lui et Maiffret découvriront des dizaines d’autres vulnérabilités critiques dans les produits Microsoft. De son côté, Permeh co-fondera plus tard Cylance, vendue à BlackBerry pour 1,4 milliard de dollars en 2020, puis rejoindra SYN Ventures comme partenaire.
Riley Hassell, le découvreur de la vulnérabilité originale, dira bien plus tard dans une interview : “J’ai publié la vulnérabilité de manière responsable. Microsoft a publié un patch. Ce n’est pas ma faute si personne ne l’a installé.” Il travaillera ensuite pour @stake, Immunity, et d’autres grandes boîtes de sécurité.
L’impact de Code Red sur l’industrie sera d’ailleurs profond et durable débutant en janvier 2002, par Bill Gates qui lancera l’initiative “Trustworthy Computing” afin que la sécurité soit au cœur du développement. Le projet Windows Server 2003 sera même arrêté pendant deux mois pour former tous les développeurs à la sécurité. C’est un tournant historique pour Microsoft.
Microsoft accélère aussi son programme de patchs mensuels “Patch Tuesday”, lancé en octobre 2003 et les entreprises commencent à prendre au sérieux la gestion des vulnérabilités. Les outils de scan automatique et de déploiement de patchs deviennent la norme et Windows Server Update Services (WSUS) est développé.
Code Red inspire aussi une nouvelle génération de malwares tel que, en janvier 2003, SQL Slammer (seulement 376 octets !) qui infectera 75 000 serveurs en 10 minutes, doublant de taille toutes les 8,5 secondes. Un record jamais battu. Puis en août 2003, Blaster exploitera une faille RPC Windows. Il y a eu également Welchia/Nachi qui tentera de nettoyer Blaster… un ver “bénéfique” mais qui en réalité causera autant de problèmes. Sans oublier Conficker en 2009 qui infectera des millions de machines.
Le Mountain Dew Code Red, la boisson qui a donné son nom au ver, profite également de la publicité gratuite. Lancé quelques semaines avant l’incident, le soda devient rapidement culte dans la communauté tech et les hackers et les admins système adoptent la boisson comme leur carburant officiel.
En 2002, David Moore, Colleen Shannon et leurs collègues du CAIDA publieront une analyse détaillée dans IEEE Security & Privacy et leurs conclusions sont glaçantes : si Code Red avait été mieux conçu, il aurait pu infecter la quasi-totalité des serveurs vulnérables en moins d’une heure. L’article devient une référence, mais aussi un manuel involontaire pour les futurs créateurs de vers. C’est le dilemme éternel de la recherche en sécurité qui est de publier pour éduquer et protéger, au risque d’armer les attaquants.
Bref, la prochaine fois que Windows vous harcèle pour installer des mises à jour, pensez à Code Red et cliquez sur “Installer maintenant” !!!
Sources : Wikipedia - Code Red , CAIDA Analysis of Code-Red , ACM SIGCOMM - Code-Red case study , Microsoft Security Bulletin MS01-033 , CERT Advisory CA-2001-19 , GIAC - The Code Red Worm , Scientific American - Code Red , GAO Report on Code Red , Microsoft Trustworthy Computing , Houston Chronicle - Code Red costs
SpaceX est un fournisseur d'accès à Internet dont la particularité est de faire transiter la connexion par l'espace, via une constellation de milliers de satellites. Son service se nomme Starlink.
Spotify à 12 balles par mois, YouTube Music et Apple Music qui vous taxe 11 euros… Franchement, à ce rythme, écouter de la musique va bientôt nécessiter un crédit à la conso chez Cofidrisse. Heureusement, un développeur nommé Valeri Gokadze a décidé de renverser la table avec Musify , une app de streaming musical complètement gratuite et open source qui fait tout pareil, mais sans vous demander un rond.
Car oui, pourquoi payer pour accéder à de la musique qui est déjà disponible publiquement ? L’app utilise les API de Piped (un frontend alternatif pour YouTube respectueux de la vie privée) pour streamer directement les morceaux depuis YouTube Music. Du coup, vous avez accès à des millions de titres sans pub, sans compte, sans abonnement et sans que Google ne vous traque comme un lapin dans la forêt.
Développée en Flutter, cette petite merveille tourne sur Android et propose des fonctionnalités qui feraient pâlir les géants du secteur. Un mode hors ligne pour écouter votre musique sans connexion, la possibilité de créer des playlists personnalisées, mais également les paroles synchronisées pour vos karaokés solo, et du SponsorBlock pour zapper automatiquement les segments sponsors dans les podcasts. Ah et cerise sur le gâteau, l’interface Material Design s’adapte dynamiquement aux couleurs de votre fond d’écran si vous êtes sur Android 12 ou plus.
Les dev ont porté beaucoup d’attention aux détails d’ailleurs… L’app propose 21 langues différentes, un thème noir pur pour les écrans OLED, et même un système d’import/export de vos données pour ne jamais perdre vos playlists. Les audiophiles apprécieront également l’optimisation sonore intégrée, tandis que les paranos de la vie privée seront ravis d’apprendre qu’il n’y a absolument aucun tracking. Pas besoin des services Google, pas de collecte de données, nada.
Bref, Musify offre une expérience fluide et agréable pour streamer de la musique, rendant la découverte de nouveaux morceaux simple et la lecture sans effort. L’app fonctionne même quand votre téléphone est verrouillé avec les contrôles média sur l’écran de verrouillage, même si le changement de piste peut parfois être un peu lent.
Pour installer Musify, vous avez maintenant plusieurs options. La plus simple reste F-Droid , sinon, vous pouvez récupérer les dernières versions directement sur GitHub ou sur le site officiel du projet . Vous téléchargez l’APK, autorisez l’installation depuis des sources inconnues, et c’est parti mon kiki !
L’app n’est disponible que sur Android pour le moment (désolé les utilisateurs d’iPhone), et comme elle dépend de YouTube pour le contenu, certains morceaux peuvent parfois être indisponibles selon votre région, mais franchement, pour une app gratuite, sans pub et open source, c’est difficile de faire la fine bouche.
Puis le code est complètement ouvert sous licence GPL v3 donc vous pouvez le forker, le modifier, l’améliorer, et pourquoi pas créer votre propre version.
Bref, si vous en avez marre de jongler entre vos abonnements streaming ou si vous cherchez simplement une alternative éthique et gratuite, Musify mérite clairement le détour.
Si vous avez déjà passé 20 minutes à déboguer un cron job qui ne se lance pas parce que vous aviez mis un espace au mauvais endroit dans la syntaxe * * * * *, vous allez adorer
CronMaster
.
Car le problème avec cron, c’est pas le concept en lui-même. L’idée de planifier des tâches automatiques reste géniale depuis les années 70. Non, le souci c’est cette syntaxe ésotérique qui fait que même les devs expérimentés doivent vérifier trois fois leur ligne avant de valider. Un petit 0 2 * * 1-5 et vous vous demandez si ça va se lancer tous les lundis ou tous les jours de la semaine à 2h du matin.
CronMaster arrive donc avec une proposition simple qui est de conserver la puissance de cron tout en rendant son utilisation intuitive. L’interface web affiche vos jobs sous forme de cartes visuelles, avec le nom de la tâche, sa fréquence d’exécution en langage humain et la possibilité de les activer/désactiver d’un clic. Plus besoin de commenter/décommenter des lignes dans le crontab.
CronMaster ne réinvente pas cron. Il se pose juste comme une couche visuelle par-dessus le système existant. Vos jobs continuent de tourner via le crontab système, mais vous les gérez depuis une interface moderne avec du dark mode, des stats système en temps réel (CPU, RAM, uptime) et même la possibilité de gérer des scripts bash directement depuis l’interface.
L’installation passe par Docker, ce qui simplifie énormément le déploiement. Un simple docker-compose.yml avec quelques variables d’environnement et vous avez votre interface accessible sur le port 40123. Le projet supporte aussi bien AMD64 qu’ARM64, donc ça tourne aussi bien sur votre serveur que sur un Raspberry Pi.
CronMaster n’est pas le seul dans sur créneau. Y’a Cronicle qui propose par exemple une solution multi-serveurs avec des graphiques de performance en temps réel et une gestion des dépendances entre tâches ou encore Crontab-UI qui mise plutôt sur la simplicité avec import/export de configurations et système de backup automatique.
Mais CronMaster a ses propres atouts. Son système d’informations système intégré permet de voir en un coup d’œil l’état de votre serveur pendant que vos jobs tournent. Et le support des variables d’environnement HOST_PROJECT_DIR facilite l’intégration dans des workflows existants. Sans oublier la possibilité de gérer plusieurs utilisateurs crontab depuis la même interface est pratique pour les équipes.
Un détail technique important… CronMaster nécessite les droits root dans le conteneur Docker pour accéder au crontab système. C’est un choix assumé du dev pour garantir une intégration transparente avec le système existant. Donc si vous préférez une approche plus isolée, Zeit propose une alternative desktop en C++ qui tournera sur votre ordi.
Le format cron reste toujours le même : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12) et jour de la semaine (0-7), mais avec CronMaster, vous avez des sélecteurs visuels qui génèrent automatiquement la bonne syntaxe comme ça, plus besoin de se rappeler que */5 signifie “toutes les 5 minutes” ou que 0,30 veut dire “à la minute 0 et 30”.
L’interface affiche aussi les logs d’exécution de chaque job, ce qui facilite grandement le debug. Au lieu de fouiller dans /var/log/syslog ou de configurer des redirections complexes avec >> /var/log/monjob.log 2>&1, tout est accessible depuis l’interface web.
Pour les développeurs qui bossent sur plusieurs projets, la fonctionnalité de commentaires sur chaque job est également super pratique. Vous pouvez documenter pourquoi tel script doit tourner à 3h du matin ou rappeler les dépendances d’un job particulier. Ces métadonnées restent attachées au job dans l’interface, contrairement aux commentaires dans le crontab qui peuvent facilement se perdre.
Voilà, donc si vous gérez régulièrement des cron jobs et que vous en avez marre de cette syntaxe cryptique, vous adorerez CronMaster !! C’est à découvrir ici !
On a déjà tous passé 10 minutes à chercher dans notre historique bash LA commande SSH avec tous les bons paramètres pour nous connecter à ce foutu serveur obscur qu’on a configuré il y a 3 mois… Port custom, clé spécifique, nom d’utilisateur bizarre… Un vrai cauchemar. Et du coup, je me suis souvenu d’un outil dont on m’avait parlé y’a pas longtemps : GGH .
Écrit en Go par Binyamin Yawitz, ce petit outil CLI garde en mémoire toutes vos sessions SSH et vous permet de les retrouver instantanément. Plus besoin de fouiller dans votre historique comme un archéologue ou de maintenir un fichier notes.txt avec toutes vos connexions.
Le principe est con comme la lune… à chaque fois que vous utilisez GGH pour vous connecter, il enregistre tout (hôte, utilisateur, port, clé). Après, vous tapez juste ggh et vous avez une liste interactive de toutes vos sessions précédentes. Vous pouvez même filtrer en tapant quelques lettres, comme ggh - stage pour retrouver tous vos serveurs de staging.
Pour l’installer, c’est rapide. Sur Unix/Linux/Mac, une petite ligne de curl :
Connexioncurl https://raw.githubusercontent.com/byawitz/ggh/master/install/unix.sh | sh
Sur Windows avec PowerShell :
powershell -c "irm https://raw.githubusercontent.com/byawitz/ggh/master/install/windows.ps1 | iex"
Ou si vous avez Go installé :
go install github.com/byawitz/ggh@latest
Une fois installé, utilisez-le exactement comme SSH. Par exemple :
ggh [email protected]
ggh [email protected] -p2222
La magie opère quand vous tapez simplement ggh sans paramètres. Vous obtenez une liste interactive de toutes vos connexions précédentes, triées par fréquence d’utilisation. Flèche haut/bas pour naviguer, Entrée pour se connecter. Simple et efficace.
Ce qui est malin, c’est que GGH lit aussi votre fichier ~/.ssh/config. Du coup, si vous tapez ggh -, vous avez accès à tous vos hôtes configurés. Et vous pouvez filtrer directement, genre ggh - prod pour voir uniquement vos serveurs de production.
Notez que GGH ne remplace pas SSH. C’est juste un wrapper intelligent qui facilite la vie. SSH doit encore être installé sur votre système pour que GGH fonctionne. L’outil se contente juste de mémoriser vos connexions et de relancer les bonnes commandes SSH.
Le projet est open source sous licence Apache 2.0, le code est propre, écrit à 80% en Go, et l’outil reste super léger. Pas de dépendances folles, pas de configuration complexe. Ça fait le job, point.
Quelques commandes utiles à connaître :
ggh --config pour voir où sont stockées vos configsggh --history pour accéder directement à l’historiqueggh tout seul pour la liste interactiveVoilà, si comme moi vous en avez marre de chercher vos commandes SSH dans votre historique ou de maintenir des alias à n’en plus finir, donnez une chance à GGH , vous m’en direz des nouvelles.
Dites en « rotation synchrone », certaines planètes ne présentent qu'une seule face à leur étoile en permanence. Pourtant, cette configuration très éloignée de celle de la Terre pourrait aussi être un bon environnement pour voir apparaître la vie.
Vous savez ce qui est frustrant quand, comme moi, on fait plein de trucs avec Claude Code ? C’est de devoir rester scotché à son ordi pour suivre l’avancement d’une build ou d’une tâche un peu longue. Heureusement des ingénieurs de San Francisco ont ressenti exactement la même frustration, et au lieu de râler dans leur coin comme des cons, ils ont créé Happy .
L’idée leur est venue dans au café où ils passaient leur temps à vérifier constamment l’avancement de leurs projets sur Claude Code. Comme ils l’expliquent sur leur site , ils checkaient leurs laptops toutes les 5 minutes pendant les pauses déjeuner et ça commençait à les relouter. Du coup, ils ont développé une solution mobile qui permet de garder un œil sur Claude Code depuis n’importe où, avec des notifications push et tout le tralala.
Happy fonctionne de la manière suivante. Sur votre machine, vous remplacez simplement la commande claude par happy dans votre terminal et l’application se charge ensuite de créer un pont chiffré de bout en bout entre votre ordinateur et votre téléphone. Comme ça, quand vous voulez contrôler Claude depuis votre mobile, le système bascule automatiquement en mode distant. Simple et efficace.
L’installation de Happy est simple. Vous téléchargez l’app iOS ou Android, puis vous installez le CLI sur votre ordi avec
npm install -g happy-coder
À partir de là, y’a plus qu’à utiliser happy au lieu de claude dans votre terminal habituel. L’interface mobile reprend alors toutes les fonctionnalités de Claude Code, avec en prime la possibilité de recevoir des notifications push quand une tâche importante se termine ou qu’une erreur survient. C’est vraiment top ! Pour tout vous dire, j’avais ce besoin et je m’étais codé une interface web accessible depuis l’extérieur de chez moi (via un VPN), avec un
terminal ttyd
dedans pour y lancer Claude Code mais c’était un peu archaïque et pas très pratique.
Niveau sécurité, Happy dispose d’un système de chiffrement de bout en bout comme ça, vos sessions Claude restent privées et sécurisées, même quand elles transitent par les serveurs de Happy pour la synchro. Les développeurs ont clairement pensé aux professionnels qui travaillent sur des projets sensibles et qui ne peuvent pas se permettre de faire fuiter du code propriétaire.
L’aspect open source du projet mérite également d’être souligné car tout le code est disponible sur GitHub, et est divisé en trois composants principaux : happy-cli pour l’interface en ligne de commande, happy-server pour le backend de synchronisation chiffrée, et happy-coder pour le client mobile.
Faut que je prenne le temps d’aller jeter un œil au code aussi pour voir comment ils encapsulent Claude Code dans leur CLI Happy et comment il lui injectent des commandes, parce que ça va me permettre de mettre au point un contrôleur tiers qui viendra faire la même chose mais pour des automatisations complètes de Claude Code (voire, pourquoi pas, pilotable par une autre IA… Du genre GPT-5.0 qui commande Claude Code…). Oui je sais, j’ai des délires chelous.
Au final, Happy résout un problème concret qu’on est nombreux à avoir. Donc pour tous ceux qui passent leur journée à coder avec Claude, pouvoir suivre et contrôler leurs sessions depuis leur téléphone change clairement les chose. Plus besoin de rester collé à son bureau pour superviser un déploiement, le dev d’un bout de code ou une suite de tests.
He Xiaopeng, le patron de Xpeng, a participé à un podcast de près de 3 heures où il a partagé plusieurs points de vue intéressants sur la marque, mais aussi la réalité du marché chinois.
