Christophe Tremblay-Guilloux @libremastercom

EspoCRM 10 est sorti le 2 juillet 2026, avec des pipelines de vente multiples et un système de verrouillage d'enregistrements. Cinq changements de compatibilité à vérifier avant la mise à jour : SelectManager retiré, accès ORM aux liaisons dépréciées supprimé, jobs par serviceName abandonnés, Espo.ui et Espo.utils retirés côté frontend. Ces suppressions cassent en silence des extensions et des personnalisations construites sur les anciennes API. Une mise à jour EspoCRM se teste sur une copie du serveur, avant d'aller en production. libremaster.com/espocrm-10-nou…

Un client ne pouvait plus saisir ses heures dans Dolibarr du jour au lendemain : une mise à jour avait cassé l'écran de saisie du temps passé. Le correctif existait déjà, intégré 14 heures avant la publication de la version buguée. Six semaines plus tard, toujours pas publié. Facturer au temps passé et ne plus pouvoir le saisir arrête la chaîne de facturation. Corrigé en 31 minutes en attendant la prochaine version officielle. libremaster.com/dolibarr-temps…

Sur un logiciel de gestion de licences en Django que j'ai écrit seul, à la main, mon client développe maintenant l'interface avec sa propre session Claude. Je découvre son code au git pull. Dans sa liste de corrections, une n'est pas un bug, ne provoque aucune erreur, ne se voit dans aucun test, et représente à elle seule 126 lignes à supprimer. Le logiciel avait deux façons de faire circuler la requête HTTP jusqu'aux journaux. La mienne, posée à la main sur chaque objet, vingt et une fois dans huit fichiers. Et celle de Claude, un mécanisme central qui publie la requête au début de chaque cycle et la retire à la fin, plus solide et plus simple. Le problème, ce n'est pas que ça marche mal. C'est que ça marche. Les deux mécanismes cohabitent, le résultat est correct dans tous les cas, personne ne voit jamais rien. Sauf que le code n'est plus vérifiable par ses effets, et que l'ancien peut même l'emporter sur le nouveau dans certains cas. En supprimant les vingt et une lignes devenues inutiles, je tombe sur celle-ci, dans la validation d'un formulaire : nalpeironlicensecode._request = self.context['request'] Cette variable n'existe pas à cet endroit. La ligne lève une erreur à chaque appel réussi de l'endpoint concerné. Elle date de juillet 2025. Elle est de moi. Je ne l'ai trouvée ni en cherchant un bug, ni en lisant les journaux, ni en écrivant un test : je l'ai trouvée parce que je supprimais du code inutile et qu'elle était dedans. J'ai détaillé le diagnostic complet, avec les autres trouvailles de la liste, dans un article. libremaster.com/le-jour-ou-cla…

Chrome vient de corriger en urgence une faille déjà exploitée par des pirates. Un simple site piégé suffit à faire exécuter du code sur votre ordinateur. Pas besoin de télécharger ni de cliquer sur quoi que ce soit d'autre que la page elle-même. Le correctif est sorti le 3 septembre : version 152.0.7977.82 sous Linux, 152.0.7977.82 ou .83 sous Windows et macOS. Chrome le télécharge tout seul en arrière-plan, mais il ne s'installe vraiment qu'au redémarrage du navigateur. Tant que vous ne le relancez pas, vous restez exposé. Pour vérifier où vous en êtes : Paramètres, puis « À propos de Chrome ». Si la version affichée est antérieure à 152.0.7977.82, laissez le téléchargement se terminer, puis fermez et rouvrez le navigateur. Les navigateurs basés sur Chromium (Edge, Brave, Opera, Vivaldi) sont concernés de la même façon et reçoivent, ou vont recevoir, le même correctif. C'est la sixième faille de ce genre corrigée sur Chrome depuis le début de l'année. Annonce officielle de Google, pour vérifier par vous-même : chromereleases.googleblog.com/2026/09/stable…

Un client m'écrit : le diaporama de sa page d'accueil ne s'affiche plus. À la place, un rectangle gris et vide, et tout le reste de la page parfaitement normal. Le reste du site s'affiche normalement, le journal PHP reste vide après rechargement, et aucune supervision n'aurait signalé quoi que ce soit. Je ne sais pas depuis quand la page d'accueil est dans cet état. Presque trois heures de recherche, avec quatre fausses pistes avant la bonne : la licence de l'extension, un doublon d'extension, une extension compagnon du thème absente, et la mise à jour du thème faite juste avant, coupable désignée par défaut. C'est la console du navigateur qui finit par parler, sur un slider créé de zéro pour tester : ReferenceError: auto is not defined at SR7.F.init (sr7.js) La cause est dans deux lignes de Slider Revolution 6.7.58, fichier includes/output.sr7.class.php : $html .= "gh:[". esc_attr($csizes['height']) ."],"; La hauteur d'un slider peut valoir auto, c'est même le réglage par défaut, et rien n'entoure la valeur de guillemets. Le JavaScript produit contient donc gh:[auto,auto,auto], ce qui n'est pas du JavaScript valide, et le moteur s'arrête à l'initialisation avant de dessiner quoi que ce soit. Trente lignes plus bas dans le même fichier, la hauteur minimale est écrite correctement, avec ses guillemets. Deux leçons pour vos propres sites. Une extension livrée avec un thème premium se met à jour quand le thème se met à jour, donc à un moment que vous n'avez pas choisi. Et quand elle n'affiche plus rien, la page continue de répondre normalement, donc aucune alerte ne part. J'ai mis dans l'article le détail des quatre fausses pistes, les erreurs de console, le code du thème qui explique pourquoi même le conteneur du slider est absent de la page, et le correctif. libremaster.com/slider-revolut…

@_adriend_ C'est parce que désormais il faut indiquer ton âge à systemd pour vérifier que tu as le droit de passer root.

Debian 11 Bullseye est en fin de vie depuis le 31 août 2026 (cinq ans après sa sortie). Plus aucune mise à jour de sécurité ne sortira pour cette version. Beaucoup ne s'en rendront jamais compte, parce que ça ne se voit pas. Sauf le jour où le serveur se fait pirater, et vu ce qui circule en ce moment, c'est une question de temps. Un petit apt upgrade continue de tourner comme avant, plus rien ne se met à jour, et vous gardez l'impression que tout va bien. Deux commandes en SSH vous disent où vous en êtes : cat /etc/debian_version lsb_release -ds Si vous voyez 11.x ou bullseye, vous êtes concerné. Le cas typique, c'est le VPS commandé en 2022 ou 2023 avec l'image Debian proposée par défaut à l'époque, mis à jour de temps en temps parce que le site marchait, mais jamais migré d'une version majeure à l'autre. Debian 12 Bookworm sera mis à jour jusqu'au 30 juin 2028, et la migration n'a rien de compliqué... sur une installation propre ;-) PHP passe de 7.4 à 8.2, et c'est là que les extensions abandonnées et les thèmes qui n'ont pas été mis à jour depuis trois ans posent problème. rsyslog laisse la place à journald (miam !), donc vos scripts de surveillance qui font un tail sur /var/log ne trouvent plus rien. Python interdit désormais l'installation de paquets en dehors d'un environnement isolé, et tout ce qui a été posé à coups de pip install est à revoir. Quant à l'Extended LTS, il ne règle rien, vu que la couverture est partielle et payante et qu'elle achète seulement du temps aux parcs qui ne peuvent pas bouger tout de suite. Les trois options, les points de rupture et la checklist de sauvegarde à faire avant de lancer quoi que ce soit sont dans l'article. libremaster.com/debian-11-fin-…

Mon client développe l'interface de son application avec sa propre session Claude, et pousse sur la branche que je récupère. Je découvre tout au git pull. Épisode 2. Cette fois, Claude a eu raison. Il a remplacé ma plomberie pour faire circuler la requête HTTP jusqu'aux logs par un middleware et un contextvar. C'est la bonne solution. C'est même celle que j'aurais dû écrire au départ. Sauf qu'il a laissé l'ancienne en place. 21 affectations dans 8 fichiers, qui ne servent plus à rien. Et ça marche. Les deux mécanismes cohabitent, la fonction de log les consulte l'un après l'autre, le résultat est correct. Personne ne verra jamais rien. C'est ça, le problème. Si une de ces vingt et une lignes disparaissait par erreur, rien ne casserait : le nouveau mécanisme rattraperait. Le code n'est plus vérifiable par ses effets. Il est devenu intestable. J'ai supprimé. 11 fichiers, 126 lignes en moins, aucun changement de comportement. Et dedans, une ligne qui lève un NameError à chaque appel réussi de l'endpoint concerné. Elle est de moi. Elle date du 9 juillet 2025. Je ne l'ai pas trouvée en cherchant un bug, ni en lisant les logs, ni en écrivant un test. Je l'ai trouvée parce que je supprimais du code inutile et qu'elle était dedans. Le code mort ne coûte pas zéro. Il coûte les pannes qu'il te cache. Le reste de ma liste est dans l'article : pourquoi .get('cle', {}) ne protège de rien quand le fournisseur envoie la clé présente à null, la mesure qui a démonté une analyse de performance qu'on me présentait comme un coût déraisonnable, et la commande de purge des logs qui écrit une ligne de log dans la table qu'elle est en train de vider. libremaster.com/claude-code-dj…

Je fais un git pull sur la branche de développement et je récupère 23 commits, environ 1 400 lignes modifiées, dont je n'ai pas écrit une seule. Le projet est un logiciel de gestion de licences en Django, que j'ai développé seul et à la main, sans IA, du premier fichier au dernier. Il attendait que mon client dégage du temps pour l'interface React, qu'il fait à 100 %. Cette phase a démarré, et depuis il code avec sa propre session Claude et pousse sur la branche que je récupère. Alors j'ai lu le diff en entier. Première trouvaille : une fonction de trois lignes qui sert à éviter une erreur de sérialisation JSON sur les dates. Elle applique le convertisseur toute seule, pour que plus personne n'ait à y penser. L'intention est bonne. Sauf que les 24 appels de cette fonction lui repassent quand même l'argument qu'elle était censée rendre inutile. Elle sérialise correctement, et elle se comporte exactement comme la fonction qu'elle remplace. L'oubli qu'elle devait rendre impossible reste possible partout. 3 de ces 24 lignes étaient de moi, d'avril et juillet 2025. Là, j'ai moins ri. Et le meilleur arrive après le nettoyage, quand j'ai posé la question qui rapporte le plus : est-ce que le problème est TOTALEMENT réglé ? Non. Une ligne de log de niveau debug, écrite en janvier 2025, qui voyage depuis 18 mois de refactor en refactor, passe un objet Django là où il faut du JSON. Le jour où ce chemin de code s'exécute, c'est une erreur 500 en production à cause d'une ligne de débogage. 25 fichiers touchés, 26 lignes ajoutées, 65 supprimées, 33 minutes. J'ai tout raconté dans l'article, avec le code et les prompts que j'ai tapés, fautes de frappe comprises. libremaster.com/le-jour-ou-cla…

WP Rocket m'a prévenu par mail que ma clé de licence et mes clés API Cloudflare avaient pu être exposées. J'ai mis à jour. J'ai vérifié derrière. Les clés étaient toujours en ligne. Depuis la 3.23.1, l'extension sauvegardait ses réglages à chaque montée de version, en JSON lisible, dans un dossier de wp-content servi par le serveur web. Dedans : l'adresse e-mail du compte, la clé de licence, les clés Cloudflare et Sucuri. Le correctif 3.23.3.3 ne protège pas cette sauvegarde. Il la supprime, et il efface les fichiers déjà écrits. C'est la bonne décision. Sauf que l'effacement ne part que si quelqu'un ouvre l'administration du site. J'ai mis à jour depuis MainWP, qui ne passe jamais par wp-admin. La mise à jour était faite, la case cochée sur mon tableau de bord, et les fichiers toujours servis par nginx. Quatre fichiers de 4 ko chez moi, un par montée de version, sur trois semaines. Si tu administres un parc WordPress à distance, ton tableau de bord ne te dira pas si tes clés sont encore en ligne. Il faut aller regarder sur le serveur. J'ai mis dans l'article la raison exacte pour laquelle le ménage ne se déclenche pas, la commande qui retrouve les fichiers, celle qui interroge les journaux d'accès pour savoir si quelqu'un est venu les chercher, et pourquoi ma réponse à cette dernière question comporte un trou d'une semaine. libremaster.com/faille-securit…

Agrandir un disque additionnel sur une instance Public Cloud OVHcloud est une opération courante de mon métier d'infogérance. Cette fois, c'est mon propre disque de sauvegarde. Le seuil que j'ai posé dessus s'est déclenché, j'ajoute de l'espace, et je le fais avec Terraform plutôt que dans le manager OVHcloud. Pourquoi sortir de l'infrastructure as code pour ce qui tient en trois clics ? Parce que l'état décrit, reste vrai après l'opération, que le changement est tracé, et que la même manipulation peut être rejouée à l'identique. Je montre le déroulé complet, vérifications comprises. #Infogérance #OVHcloud #ServeurLinux

⏰

@AldoSterone111 Il y a une intervention en cours sur les 100k serveurs qui hébergent ton VPS à cause d'une faille de sécurité critique. En théorie le VPS est relancé dans les 30 minutes sinon c'est un bug et il faut déclarer un incident.

Deux façons de passer la nuit à forcer dans le noir pour rien : un serveur down à 3h du matin. (L'autre restera dans les annales.) Tu te dis que ça va prendre 5 minutes. C'est souvent comme ça que commencent les longues soirées. On cherche un détail, puis une cause, puis une autre. Et sans s'en rendre compte, on passe plusieurs heures sur un problème qui n'aurait jamais dû exister. J'ai moi aussi passé des nuits devant un écran. Mais je préfère les consacrer à construire, expérimenter ou comprendre quelque chose de nouveau. Pas à intervenir manuellement sur des problèmes qui auraient dû être anticipés. Le problème n'est pas la panne. C'est que chaque incident exige une intervention manuelle. Tant qu'un serveur a besoin de toi pour retrouver un état normal, la prochaine nuit blanche est déjà programmée. Et là, tu es devenu une partie du système. Si chaque incident dépend d'une personne, c'est cette personne qui devient le risque. Personne ne planifie une nuit blanche. Les infrastructures difficiles à maintenir ne naissent pas d'une mauvaise décision, mais de dizaines de décisions raisonnables prises dans l'urgence et jamais remises en question. Un exemple. Un serveur hébergeait une cinquantaine de sites. Une panne le premier jour. Une autre le lendemain. Une dernière le troisième jour pendant plusieurs heures. Le système a été remplacé par un nouveau serveur sous stack SYSMASTER, un modèle testé et contrôlé sur d'autres infrastructures. Depuis, plus aucune intervention nécessaire côté client. Le piège du moment : après deux heures de recherche, ton IA te propose une commande que tu n'as jamais vue. Elle semble cohérente. Tu l'essaies. Puis une autre. Puis une autre. À chaque tentative, tu espères résoudre le problème sans en créer un nouveau. Le jour où tu appliques des solutions que tu ne maîtrises plus complètement, le problème n'est déjà plus la panne. C'est que tu es en train de perdre le contrôle. Tu n'as pas besoin d'une nouvelle nuit blanche pour comprendre ce qui doit changer. Découvre la stack SYSMASTER. Télécharge l'ebook : libremaster.com/sysmaster #Infogérance #Supervision #Serveurs

@Solylex @Brain0verride Alors j' ai commencé à partager mon code terraform et puppet avec Claude et ça fait gagner du temps, il n'a pas accès aux variables hiera ni aucune clé API avec droit d'écriture, je vérifie ce qu'il fait et je lance les commandes moi-même.

Le jour où ton serveur Linux te lâche, tu découvriras si tu avais un plan ou un espoir. Tu connais déjà la réponse, non ? Tu restes le responsable, même quand tu n'es pas le spécialiste. Le serveur n'est pas ton métier. Pourtant c'est toi qui devras répondre aux questions, gérer l'urgence et rassurer le client si quelque chose tourne mal. Après 25 ans sur Debian, je sais où commencent les ennuis. Rarement dans une panne. Presque toujours dans un sujet important qui dépend d'une personne déjà occupée par autre chose. Le problème n'est donc pas le serveur. C'est la responsabilité qu'il représente. Car c'est toi que le client appellera, même si le serveur n'est pas ton métier. Et plus tu avances sans visibilité claire sur l'état réel du serveur, plus tu comptes sur le fait que rien n'arrive. L'espoir remplace souvent la visibilité. Ce qui protège un serveur, c'est la continuité. Pas une intervention d'urgence. Pas une vérification occasionnelle. Mais des tâches critiques suivies régulièrement, même lorsque tu as autre chose à faire. Les meilleurs changements sont souvent invisibles. Les applications restent les mêmes. Les sites aussi. Ce qui change, c'est qu'une responsabilité portée seul devient un sujet suivi en continu. Et si le serveur cessait enfin d'être un sujet ? Plus besoin de te demander quand trouver le temps de t'en occuper. Tu te concentres sur les projets, en sachant que l'infrastructure continue d'être suivie. Continuer comme aujourd'hui reste un pari. Le pari que le prochain incident n'arrivera pas pendant tes vacances, un week-end ou sur le projet d'un client important. La stack SYSMASTER existe pour une raison : retirer le serveur de ta liste de préoccupations. Télécharge l'ebook : libremaster.com/sysmaster #Infogérance #Supervision #Serveurs

Ton serveur Linux ne sait pas que tu es en congé. Et c'est précisément le problème. Tu as parfaitement le droit de partir. Tu peux laisser ton ordinateur à la maison et profiter de tes vacances. Mais ton départ ne change rien à ce qui se passe autour de tes serveurs. La seule chose qui disparaît, c'est ta disponibilité. Après 25 ans sur Debian, j'ai appris une chose : les événements importants choisissent rarement un moment pratique. Ils arrivent quand ils arrivent. La vraie question n'est pas de savoir si tu es disponible, mais ce qui se passe quand tu ne l'es pas. Beaucoup de responsables regardent la stabilité de leurs serveurs pour décider s'ils peuvent partir. Pourtant, ce n'est pas la stabilité qui est testée pendant les vacances. C'est la dépendance de l'infrastructure à leur présence. Le risque, lui, ne part pas avec toi. Les sites continuent de recevoir du trafic. Les attaques continuent. Les certificats expirent. Les fournisseurs ont des incidents. Si la seule chose qui disparaît est ta capacité d'intervention, c'est elle qui détermine le niveau réel de risque. L'objectif n'est donc pas d'être joignable. Les infrastructures les plus sereines ne reposent pas sur la réactivité de leur responsable. Elles sont organisées pour que les tâches critiques restent surveillées, traitées et suivies, même en son absence. Fais le test : quinze jours sans ordinateur, sans VPN, sans accès à tes outils habituels. Qu'est-ce qui continuerait à fonctionner exactement comme aujourd'hui ? Les vacances ne créent pas la dépendance. Elles la révèlent. Tant que ton absence augmente le niveau de risque, chaque nouveau site, chaque nouveau client et chaque nouveau serveur renforcent une responsabilité qui repose encore principalement sur toi. La stack SYSMASTER existe pour une raison : retirer le serveur de ta liste de préoccupations. Garder le contrôle sans rester le point de défaillance. Télécharge l'ebook : libremaster.com/sysmaster #Linux #SysAdmin #Debian

La semaine dernière j'ai mis à jour pfSense de 2.7.2 à 2.8.1. C'est mon proxy et mon VPN pour accéder de façon sécurisée à l'administration des serveurs que je gère. Le changement majeur de cette version : le passage de FreeBSD 14 à FreeBSD 15. Deux ans de développement FreeBSD intégrés d'un coup. Correctifs noyau, gains de performance, et PHP qui passe de 8.2 à 8.3. Côté VPN et accès distant : OpenVPN pousse maintenant la config par client directement depuis la GUI, et l'accélération crypto passe automatiquement par OpenSSL. IPsec, avec strongSwan mis à jour, corrige le ralentissement des règles firewall quand beaucoup de tunnels sont actifs. OpenSSH suit FreeBSD 15 avec la correction d'une faille de divulgation de clé via la console SSH. Les algorithmes obsolètes restent supprimés : 3DES, Blowfish, CAST128, MD5-HMAC. Côté serveur DHCP avec Kea : haute disponibilité DHCPv4 et DHCPv6 en hot standby, baux synchronisés et chiffrés. Enregistrement DNS automatique des hôtes dans Unbound, configurable par interface. Délégation de préfixe DHCPv6 et configuration JSON personnalisée pour les options non couvertes par la GUI. Côté sécurité : la politique d'état par défaut passe de Floating à Interface Bound. La récupération de passerelle purge automatiquement les états sur les passerelles de secours quand la principale revient. Et NAT64 est désormais pleinement supporté, des clients IPv6 only vers des hôtes IPv4, intégré au firewall, aux annonces routeur et au DNS Resolver. Ce n'est pas une mise à jour anodine. Le saut FreeBSD 14 vers 15 impose de désinstaller tous les paquets tiers avant de lancer l'upgrade, puis de les réinstaller après. Le bootloader doit être mis à jour pour supporter le nouveau noyau, surtout avec ZFS. Ce type d'opération ne se voit jamais. Jusqu'au jour où elle n'a pas été faite. pfSense fait partie de la stack SYSMASTER. C'est par là que passe chaque connexion d'administration aux serveurs. Le détail de la stack complète est ici : libremaster.com/sysmaster

Gérer ses emails avec un boulet au pied Tu peux quitter ton hébergeur web en une journée. Pas tes emails. Un site web se déménage avec un dump SQL et un rsync. Une boîte mail, c'est autre chose. Les comptes, les filtres, les anciens messages, les enregistrements DNS, la configuration anti-spam : tout est interconnecté et lent à transférer. L'antispam analyse chaque email entrant en profondeur (contenu, headers, réputation, scoring bayésien). C'est un traitement gourmand qui s'accumule sur le serveur. La gestion du spam est devenue une discipline à part entière : configurer SPF, DKIM, DMARC, surveiller la réputation IP, maintenir un antispam à jour, gérer les bounces et les plaintes qui remontent automatiquement. Le jour où tu veux changer d'hébergeur, le déménagement est techniquement possible mais lourd. Il faut transférer les historiques par avance, reconfigurer les clients Outlook ou Apple Mail des utilisateurs, coordonner les bascules DNS, et accompagner chaque personne pas à pas. C'est un projet long et dépendant de l'implication de chacun, qu'on évite de relancer. Le mail est probablement la seule décision technique pénible à défaire. C'est pour ça que l'infogérance Linux SYSMASTER se concentre sur le web hosting et laisse le mail à des services spécialisés (Google Workspace, Microsoft 365, ProtonMail Pro pour la messagerie ; SendGrid, Brevo pour le transactionnel). Le détail de la stack ici : libremaster.com/sysmaster #Mail #Email #Antispam #Infogérance #Linux #Debian #FreelanceTech #AgenceWeb #Hébergement

VPS, Public Cloud ou dédié ? Un choix sur trois cache un piège qu'on te vend rarement. Si tu héberges un site web, le choix par défaut est souvent un VPS. Ce n'est pas toujours le bon. Entre VPS, Public Cloud et serveur dédié, les différences vont au-delà du prix d'entrée. Le critère le plus regardé reste le SLA. Un SLA est une garantie contractuelle, pas technique. Si le fournisseur ne tient pas le pourcentage annoncé, il rembourse partiellement. Ça ne veut pas dire que la machine ne tombera jamais. Le VPS chez OVH a un SLA de 99,95 % et tourne sur du matériel mutualisé. Adapté à une petite app peu critique, avec un budget serré. Le Public Cloud OVH a un SLA de 99,99 %, ressources garanties par instance, pas de voisinage gênant. C'est le défaut moderne pour un site qui doit tenir. Le dédié ADVANCE reste à 99,95 %. Il devient pertinent quand tu veux poser ton propre hyperviseur (Proxmox), ou quand tu as besoin de gros volumes en continu et tu acceptes le SLA inférieur pour économiser. Le dédié haut de gamme atteint 99,99 % mais à un prix qui rejoint celui du Public Cloud. Le réflexe « petit site égale VPS » n'est plus systématiquement le bon. La vraie question est : quel niveau de garantie contractuelle tu veux pouvoir tenir, et avec quel socle technique en dessous. L'infogérance Linux SYSMASTER part du choix de la machine adapté au SLA visé et pilote la stack technique Debian derrière. Le détail est ici : libremaster.com/sysmaster #VPS #PublicCloud #ServeurDédié #SLA #Infogérance #Linux #Debian #FreelanceTech #AgenceWeb