Fuite de données personnelles : que faire après DGFiP et Intermarché ?

Il y a des semaines où l’actualité tech ressemble à un générique de fin qu’on n’arrive pas à arrêter. Mi-août 2026 : Bercy confirme que le système d’information de la DGFiP a été victime d’un accès illégitime fin juin, avec extraction de données pour plus de 678 000 particuliers et professionnels — noms, revenus fiscaux, taux d’imposition, parfois plus. Quelques jours plus tôt, c’était Intermarché : près de 300 000 clients du service Drive avec leurs nom, prénom, date de naissance, adresse et numéro de téléphone dans la nature après un accès non autorisé aux systèmes du Groupement Mousquetaires.

Le fisc et le supermarché du coin. Si même eux y passent, personne n’est à l’abri — et ça tombe bien, parce que je voulais justement vous parler de ma propre expérience du sujet.

Le jour où j’ai vraiment regardé

Comme beaucoup de gens qui bossent dans la tech, je pensais être plutôt prudente. Mots de passe changés de temps en temps, méfiance de base sur les mails louches. Et puis un jour, par curiosité (ou plutôt par un léger sentiment d’urgence après avoir vu passer les nouvelles du mois), j’ai vraiment vérifié où mes données avaient pu fuiter au fil des années.

La liste de toutes mes fuites de données !
ça pique. Et certaines sont dues à des mots de passe répétés !

Le résultat n’était pas franchement flatteur : dix-huit fuites, étalées entre 2008 et 2025. Adobe (2013), LinkedIn (2012), Tumblr, MySpace, Lastfm, mon propre hébergeur OVH (2015), et puis toute une série d’agrégats de fuites plus récents et moins glamour — Collection1, Cit0day, des listes de credential stuffing datant de 2024 et 2025. Dix-huit lignes, dix-huit rappels que j’avais un compte quelque part il y a quinze ans et que je n’y avais plus pensé depuis.

Ce qui m’a le plus surprise, ce n’est pas le nombre en soi. C’est de réaliser que ces fuites ne sont pas des événements isolés qu’on subit une fois et qu’on oublie. Ce sont des données qui circulent, se recombinent, s’agrègent dans des bases de plus en plus complètes — et qui, des années après, peuvent encore servir à quelqu’un pour deviner un mot de passe, usurper une identité ou monter une arnaque bien ciblée.

Mais concrètement, ça sert à quoi de voler ces données ?

C’est la question qu’on oublie souvent de se poser. Une fois volées, ces données ne restent pas sagement dans un coin : elles sont revendues ou publiées sur des forums spécialisés, parfois sur ce qu’on appelle le dark web — une partie d’internet qui n’est pas indexée par Google et qui demande un logiciel particulier pour y accéder, ce qui la rend plus difficile à surveiller pour les autorités. Là, elles sont rachetées par d’autres personnes malveillantes, qui les utilisent de plusieurs façons : tester automatiquement le même mot de passe sur des centaines de sites différents (dans l’espoir que vous l’ayez réutilisé), envoyer des mails ou SMS de phishing très personnalisés parce qu’ils connaissent déjà votre nom, votre banque ou votre enseigne habituelle, ou encore usurper votre identité pour ouvrir un crédit, un abonnement ou une carte à votre nom. Plus les fuites s’accumulent et se recoupent au fil des années, plus le profil qu’on peut reconstituer sur quelqu’un devient précis — et plus les arnaques qui en résultent sont crédibles. C’est tout l’enjeu : une seule fuite isolée est gênante, mais dix-huit qui s’additionnent sur quinze ans, c’est un dossier presque complet sur une personne.

Ce que j’ai fait (et que vous pouvez faire sans être pro)

Pas de panique, rien de ce qui suit ne demande de savoir coder. Voici, dans l’ordre où je m’y suis attelée, ce qui compte vraiment :

1. Sécuriser sa boîte mail en priorité absolue. C’est la clé qui ouvre toutes les autres portes : qui accède à votre mail peut réinitialiser à peu près tous vos autres comptes. Mot de passe unique, double authentification activée (pas par SMS si possible, plutôt une appli comme Proton Authenticator ou Google Authenticator).

2. Arrêter de réutiliser ses mots de passe. Le vrai danger d’une fuite, ce n’est pas tellement que ce mot de passe précis soit connu — c’est que s’il est réutilisé ailleurs, un pirate peut l’essayer sur votre banque, vos réseaux sociaux, votre messagerie. Un gestionnaire de mots de passe (Proton Pass, Bitwarden, et d’autres existent) génère et retient des mots de passe aléatoires à votre place. C’est le changement qui a eu le plus d’impact pour moi.

3. Se faire prévenir automatiquement. Le site Have I Been Pwned permet d’activer une alerte par email : dès qu’une nouvelle fuite mentionne votre adresse, vous êtes prévenue. Ça prend deux minutes à configurer et ça évite de découvrir les choses cinq ans plus tard, comme moi.

4. Utiliser des adresses email jetables (alias) pour les nouveaux comptes. Plutôt que de donner sa vraie adresse à chaque site où on s’inscrit, un alias génère une adresse unique par service. Si elle fuite ou se met à recevoir du spam, on la désactive, et le reste de nos comptes n’est pas concerné. Proton Mail et Proton Pass proposent ça nativement, mais il existe d’autres services équivalents.

5. Faire le ménage dans les comptes qu’on n’utilise plus. MySpace, Tumblr, Lastfm… est-ce que j’ai encore besoin de ces comptes ? Non. Un compte fermé ne peut plus fuiter une seconde fois. La meilleure façon de protéger une donnée, c’est encore de ne plus la laisser traîner quelque part.

6. Rester vigilante sur le phishing, surtout après une fuite qui vous concerne. Avec des données comme un nom complet ou un numéro de carte de fidélité en circulation, les tentatives d’arnaque deviennent plus crédibles, plus personnalisées. Le réflexe qui sauve : ne jamais cliquer sur un lien dans un mail « urgent » (banque, colis, impôts justement), et toujours retaper l’adresse du service à la main.

Ce que les affaires DGFiP et Intermarché nous rappellent

Ces deux fuites ont un point commun frappant : dans les deux cas, ce ne sont pas les utilisateurs qui ont fait une erreur. Ce sont les systèmes des organisations elles-mêmes qui ont été compromis. On peut faire absolument tout comme il faut de son côté — mot de passe fort, 2FA partout — et se retrouver quand même exposée parce qu’une administration ou une enseigne où l’on a un compte a été piratée.

Ça ne veut pas dire que la vigilance individuelle ne sert à rien — au contraire, c’est elle qui détermine si une fuite reste un simple embêtement ou se transforme en vol d’identité en règle. Mais ça change la question qu’on devrait se poser : pas « est-ce que je vais me faire avoir un jour », mais « quand ça arrivera, est-ce que je serai prêt.e ? »

La checklist minute

Si vous ne devez retenir que trois choses de cet article :

  • Allez activer une alerte sur haveibeenpwned.com, ça prend deux minutes.
  • Installez un gestionnaire de mots de passe et arrêtez de réutiliser le même partout.
  • Activez la double authentification sur votre boîte mail, aujourd’hui, pas la semaine prochaine.

Le reste peut attendre un dimanche pluvieux. Ces trois-là, non.

Le dépoussiérage de mon appli de bioinformatique : partie 2 – La librairie

Trois jours, cinq sessions accompagnée de Claude, un projet qui traînait du PHP 7.2 et du Symfony 4 comme un vieux pull qu’on n’ose plus jeter. Voici comment BioPHP, ma librairie de bioinformatique, s’est retrouvée propulsée jusqu’à PHP 8.5 et Symfony 7 — avec au passage quelques bugs qui n’attendaient qu’un changement de contexte pour sortir du bois.

Jour 1 : le grand dépoussiérage des dépendances

Tout commence par un composer install --dry-run qui recrache six blocages d’un coup : PHPUnit 7.5 has-been, twig 2.5 signalé par l’audit sécurité, guzzle 6.x dans le même sac, un doctrine/rst-parser cassé, et un conflit entre phpdocumentor et twig. Rien d’insurmontable, mais rien qui se règle non plus en tournant les yeux ailleurs.

Première décision : monter PHPUnit en 8.x, twig en 3.17, et sortir purement et simplement phpdocumentor du composer.json — aucune version stable ne réconciliait PHP 7.2 et twig 3, et le paquet n’était de toute façon utilisé nulle part dans le code.

Une fois composer install vert, la suite de tests, elle, ne l’était pas : setUp() incompatible avec la nouvelle signature de PHPUnit 8 (: void), à corriger sur 16 fichiers d’un coup. Puis, sur les 121 tests restants, trois problèmes bien réels apparaissent :

  • AminoApiTest appelait la vraie API en ligne, dont la réponse avait changé entre-temps (une clé manquante).
  • PKApiTest avait sa seule méthode de test… commentée.
  • testFindZScore comparait des flottants calculés à des valeurs attendues codées en dur avec moins de décimales.

Les deux derniers ont attendu leur tour (ils reviendront), mais AminoApiTest a eu droit à un vrai traitement : garde isset() côté production pour ne plus planter quand l’API omet légitimement un champ (codon STOP, codes ambigus), poids résiduels biologiquement corrects ajoutés à la fixture, et surtout un MockHandler Guzzle pour ne plus dépendre du réseau à chaque run de test.

Dernier chantier du jour : le ménage des paquets abandoned. sensio/framework-extra-bundle disparaît (zéro usage réel), doctrine/annotations devient une dépendance explicite plutôt que tirée en douce par sensio. csa/guzzle-bundle, lui, reste — actif dans 15 classes Api/*, le remplacer aurait cassé l’API publique de Bioapi.php sans bénéfice immédiat.

121 tests / 252 assertions à la fin de cette première manche. Rien de committé — tout reste dans l’arbre de travail, en attente de validation.

Jour 1, suite : Symfony 5, puis 6, puis le grand ménage Guzzle

La même journée continue avec la montée vers Symfony 5.4 (LTS). Et c’est là qu’un détail technique révèle un vrai problème : --ignore-platform-req=php, utilisé depuis le début pour contourner le PHP 8.5 local, désactivait en réalité la vérification de compatibilité PHP partout dans la résolution des dépendances, pas seulement à la racine. Remplacé par une simulation honnête (config.platform.php = 7.2.5), la vérité éclate : sous contrainte PHP 7.2 réelle, aucune version de twig ne concilie compatibilité et correctif de sécurité critique. Même verdict pour guzzlehttp/psr7, plafonné par csa/guzzle-bundle.

Plutôt que d’accepter le risque, direction la sortie de secours : csa/guzzle-bundle est retiré, guzzlehttp/guzzle requis en direct, le client bioapi reconstruit à la main en XML de service. Bonus inattendu : twig redevient un simple outil de dev, sortant tout risque sécurité du périmètre de production. Les 15 classes Api/* n’ont même pas eu besoin de changer — l’API fluide de Guzzle 7 est restée identique à celle de Guzzle 6.

Le PHP local (8.5) satisfaisant désormais réellement ^8.1, la simulation de plateforme devient inutile. composer.json vise PHP 8.1, Symfony passe en ^6.4, composer audit tombe à zéro alerte de sécurité.

Reste un dernier paquet abandonné coriace : doctrine/annotations. Sa disparition profite d’un heureux hasard — PHP 8.1 permet les attributs natifs, et les 11 entités Doctrine du projet peuvent être converties d’un coup, des docblocks @ORM\... vers les attributs #[ORM\...]. C’est en écrivant un script de contrôle pour forcer le vrai chargement des métadonnées (aucun test existant ne le faisait, tous mockaient EntityManager) qu’un bug dormant remonte : Sequence::$primAcc empilait six annotations de relation contradictoires sur une seule propriété scalaire, dont une pointant vers une classe ScForm qui n’a jamais existé — une faute de frappe pour SrcForm, jamais détectée parce que les docblocks toléraient ce genre d’empilement silencieusement. Les attributs PHP, eux, refusent net (« Attribute must not be repeated »). Comme rien dans le code n’utilisait primAcc comme une vraie relation, les six attributs cassés sont retirés sans regret.

Jour 2 : valider en profondeur, puis viser Symfony 7

Nouvelle session, nouvelle question de cadrage : la cible Symfony 6.4 était déjà en place, mais est-ce que ça marche vraiment ? Les tests mockent EntityManager et Guzzle, ils n’exercent jamais le vrai câblage Symfony. Direction : faire booter un vrai conteneur.

Bien m’en a pris. Premier bug réel : getAlias() sans type de retour : string, requis par la classe de base sous Symfony 6.4 — une erreur fatale au chargement du bundle, invisible pour tout test existant jusque-là. Un test permanent est écrit pour ne plus jamais perdre ce genre de chose : il fait tourner le vrai MergeExtensionConfigurationPass, instancie une vraie AminoApi depuis le conteneur, vérifie que les 11 entités chargent leurs métadonnées via le pont réel Symfony/Doctrine.

Fort de cette base solide, cap sur Symfony 7 : PHP passe à ^8.2, toute la famille Symfony à ^7.4, et surtout Doctrine ORM passe en 3.6 — ce qui élimine automatiquement le dernier paquet abandonné, doctrine/cache. Ce même test permanent attrape immédiatement un second bug : getConfigTreeBuilder() sans type de retour, requis par Symfony 7.

PHPUnit doit suivre le mouvement jusqu’en 11.5 (Doctrine ORM 3.6 utilise des types union avec enum que le générateur de mocks de PHPUnit 8.5 ne sait pas reproduire), ce qui impose de migrer 16 appels setMethods() → onlyMethods() et 19 appels ->will($this->returnValue()) → ->willReturn().

Et puis, enfin, les deux problèmes préexistants depuis le premier jour trouvent leur solution. PKApiTest n’était pas juste désactivé par prudence : il était cassé dès l’origine, un cast d’objet à propriétés privées produisant des clés PHP « mangled » impossibles à comparer. Réécrit avec un vrai mock HTTP. Et testFindZScore : les valeurs attendues étaient simplement tronquées à la saisie, corrigées par régénération en pleine précision flottante.

123 tests / 262 assertions, 0 échec, 0 erreur. Les deux bugs les plus anciens du projet, enfin clos.

Jour 2, suite : la chasse aux dépréciations (et trois vrais bugs en prime)

Passer tous ces caps ne veut pas dire que tout est propre : 93 dépréciations PHP traînaient encore, toutes du même type — des paramètres string $x = null sans le ? explicite, dépréciées depuis PHP 8.4. Trois interfaces et quatre implémentations corrigées en miroir, une recherche exhaustive confirme qu’il n’en reste aucune.

Une fois ce ménage fait, 33 nouvelles dépréciations apparaissent (propriétés dynamiques non déclarées, dépréciées depuis PHP 8.2) — neuf fichiers de tests à corriger, et un faux positif écarté après vérification manuelle (un bug de portabilité sed/grep sur macOS dans le script de détection, pas un vrai problème).

Résultat : 0 dépréciation. Mais le plus intéressant de cette journée, ce sont les trois bugs signalés en relisant le code, indépendamment de l’audit :

  1. RestrictionEnzymeManager::fetchCutposAndPlen() accumulait ses résultats dans une variable inexistante, $RestEn_List[], au lieu de $aEnzymes — la méthode réelle. Résultat : un tableau toujours vide, quels que soient les enzymes correspondants. Le test associé attendait lui-même un tableau vide, ce qui masquait le bug depuis sa création.
  2. SequenceManager::getBridge(), marqué d’un @todo inquiet (« Correct it – does not seems to work :/ ») sans test dédié. Après calcul manuel, test empirique exhaustif et comparaison ligne à ligne avec le Legacy : verdict, pas de bug — juste du doute jamais vérifié. Trois tests ajoutés, le @todo obsolète retiré.
  3. SequenceManager::complement() : la table de correspondance ne couvrait que les 4 bases canoniques. Tout code d’ambiguïté IUPAC (N, Y, R, W, S, K, M, D, V, H, B) provoquait un accès à une clé absente, et le caractère disparaissait silencieusement du résultat — complement("ACGTN") renvoyait 4 caractères au lieu de 5, avec décalage de position en aval. Une table de repli IUPAC règle le problème, et un symbole réellement inconnu lève désormais une exception explicite plutôt que de tronquer en silence.

129 tests / 268 assertions.

Jour 2, fin : CI, merge de conflits, et un warning qui trompe tout le monde

Dernier acte du jour : Travis CI ne tournait plus depuis longtemps (PHP 7.2 sur Ubuntu Trusty, toutes deux retirées du support). Migration vers GitHub Actions, matrice PHP 8.2 à 8.5, coverage uploadé vers Codecov sans token en clair cette fois.

Puis vient le merge develop → master, avec des conflits d’abord perçus comme injustifiés — jusqu’à vérification : bien réels, master ayant continué de vivre de son côté sur les mêmes entités que develop modernisait. Premier réflexe, git checkout --theirs sur les 10 fichiers en conflit : mauvaise idée, ça écrase aussi des hunks non conflictuels que git avait déjà fusionnés proprement, cassant 9 tests fraîchement arrivés. Les neuf entités sont reconstruites une par une, en combinant à la main les attributs ORM de develop et le pattern défensif de master (valeurs par défaut, types nullables).

Cerise sur le gâteau : après le merge, les jobs GitHub Actions passaient à 122 tests réussis… mais échouaient quand même. Cause : PHPUnit 11 fixe failOnPhpunitWarning à true par défaut, et le seul warning émis — « No code coverage driver available » — suffisait à faire échouer le process sur tous les jobs sans xdebug. Un simple failOnPhpunitWarning="false" dans phpunit.xml, et tout redevient cohérent.

140 tests / 324 assertions, 0 échec.

Jour 3 : ressusciter les parseurs Legacy

Le dossier Legacy/ de BioPHP portait à l’origine 20 formats de bases biologiques différentes. Un audit complet du 12 août avait révélé que la refonte n’en couvrait que 2 — GenBank et Swissprot — sur les 11 223 lignes de code historique, environ 61 % restaient purement absents.

Cette session traite la « Priorité 2 » de la feuille de route : quatre nouveaux parseurs, chacun suivant le schéma déjà posé par ParseGenbankManager — EMBL, dont le stub Legacy s’arrêtait en réalité au premier // sans jamais implémenter la moitié de ses propres champs déclarés ; PDB, où un portage ligne à ligne de la classe monolithique de 1845 lignes aurait été disproportionné, donc ciblé sur l’essentiel (séquence, structure secondaire, coordonnées atomiques) ; PROSITE, dont le Legacy contenait un vrai bug de variable jamais définie (heureusement du code mort) ; et ExPASy ENZYME, porté fidèlement, nomenclature EC à ne pas confondre avec les enzymes de restriction déjà couvertes par ailleurs.

Le parseur PDB révèle au passage un nouveau bug de régression : DatabaseManager::line2r() ne reconnaissait que // comme terminateur d’entrée — la convention GenBank/EMBL/Swissprot. Un fichier PDB, qui se termine par END, provoquait une boucle infinie jusqu’à épuisement mémoire. Corrigé, avec en prime une garde de fin de fichier qui manquait entièrement et protège désormais tous les formats contre un fichier tronqué.

Petit débat d’architecture au passage : les nouveaux objets structurés pour PDB, PROSITE et ExPASy (atomes, hélices, feuillets, références croisées) avaient d’abord été nommés *DTO et rangés sous Domain/. Rejeté après revue — dans ce projet, Domain/ ne connaît que des entités, et « DTO » est réservé à la frontière HTTP. Nouvelle convention actée : un dossier neutre Domain/Model/ pour tout ce qui est structuré sans être persisté ni exposé en API.

170 tests / 496 assertions pour clore ces trois jours.

Je peux lancer avec quelques réserves toutefois, 7 ans après le début de son développement, le lancement de la version 1.

Ce qu’il reste à faire

Le noyau (séquence, alignement, GenBank/Swissprot, enzymes de restriction) est solide et testé. Quinze parseurs de bases externes restent à porter — KEGG et ses 1672 lignes en tête, à décomposer en services distincts plutôt qu’en portage monolithique. Et comme toujours dans ce genre de session marathon : rien n’est committé tant que je n’ai pas tout revalidé à froid.

Ce qui me marque, en écrivant ce billet : presque tous les vrais bugs trouvés pendant ces trois jours n’avaient rien à voir avec la modernisation elle-même. Ils dormaient dans le code depuis des années — une variable mal nommée, un @todo jamais vérifié, une table de correspondance incomplète — et c’est le simple fait de tout revalider en profondeur, pas seulement de faire passer composer install, qui les a fait remonter.

Le dépoussiérage de mon appli de bioinformatique : partie 1 – L’API

Comment une simple erreur 500 sur une API Symfony m’a entraînée dans une modernisation complète — Composer, Deployer, migration PHP 8 et pièges Doctrine compris.

Cette fois, je savais dès le départ à quoi m’attendre. Un projet qu’on laisse dormir plusieurs années ne se réveille jamais avec un simple git pull : il se réveille en mission archéologique, couche après couche. Alors avant même de lancer la première commande, j’avais le bon état d’esprit : creuser, documenter, ne pas m’énerver quand une correction en révèle trois autres en dessous. Et cette fois, j’avais un luxe que je n’avais pas les fois précédentes où j’ai fouillé seule dans un vieux projet : une IA à mes côtés pour diagnostiquer plus vite, remonter aux vraies causes sans tourner en rond, et garder une trace claire de chaque strate retirée.

Au départ de cette fouille : une erreur 500 anodine sur api.amelayes-biophp.net, mon API bioinformatique en Symfony 4 / API Platform. À l’arrivée : une remise à plat de toute ma chaîne, de Composer jusqu’au fond de mon deploy.php, une bibliothèque republiée et une migration Symfony sur trois versions d’un coup. Je vous raconte tout, parce que le vrai fil rouge de cette histoire n’est pas un bug précis : c’est la dette technique et la dépréciation qui s’accumulent en silence sur un projet qu’on laisse vivre sa vie.

Ha oui et pour les dictateurs de la bonne conscience (car j’y ai eu droit un jour à la question) : Mai pourkoua vou ne l’avai pa fini ???? Parce que c’est un side-project donc qui dit side-project dit sur son temps libre, parce que ma maman a eu de graves soucis de santé, parce que mon papa a quitté ce monde, parce que la maison, parce que les clients c’est plus important. Et à moment donné j’ai eu envie de m’évader sur des blocs virtuels empilés les uns sur les autres. Et ça c’est aussi un beau side-project. Sans rire. Ce ne sont pas des excuses, mais juste la vie. Et je vais être honnête : sans l’IA, je n’aurais pas remis les mains dans ce cambouis.

Le déclencheur : Composer 1 n’existe plus

Tout part d’une envie simple : mettre à jour l’API. Je lance un composer install de routine, et là, mur. Une vingtaine de paquets « introuvables ». Symfony, Doctrine, API Platform… tout d’un coup « could not be found ».

La vraie cause, tout en haut de la sortie :

Support for Composer 1 has been shutdown on September 1st 2025.

Mon Composer était resté en version 1, et Packagist a coupé le support. Mon vendor/ était bancal parce qu’un vieux composer install avait échoué à moitié, et c’est ça qui faisait planter l’API. Première leçon, valable pour toute la suite : la dépréciation ne prévient pas, elle attend que vous reveniez sur le projet pour se rappeler à vous.

Le piège s’est doublé aussitôt : sur mon Mac, macOS n’était plus supporté par Homebrew, donc brew cassé, donc composer self-update impossible. Pour réparer un outil, j’avais besoin d’un autre outil que je ne pouvais plus mettre à jour. Solution pragmatique : récupérer le .phar de Composer 2 en direct, sans passer par Homebrew.

Le deploy.php : un fichier plein de décisions devenues obsolètes

C’est ici que l’histoire devient vraiment parlante. Mon fichier de déploiement Deployer n’était pas juste cassé : il était rempli de déclarations qui avaient eu une bonne raison d’exister un jour, et qui étaient devenues du poids mort, voire nuisibles, sans que rien ne me le signale.

Le hostname manquant. host('bioapi-prod') n’avait pas de ->set('hostname', ...). Ça marchait avant, grâce à un alias SSH dans un ~/.ssh/config sur une autre machine — jamais versionné, donc invisible dès que j’ai changé de poste. Rien dans le fichier ne documentait cette dépendance externe.

Le ->stage('prod') devenu un vestige. Syntaxe standard en Deployer 6 pour sélectionner un environnement. En Deployer 7, ce mécanisme de stage disparaît : dep deploy prod devient dep deploy bioapi-prod, via l’alias d’hôte directement. Le ->stage() traînait sans plus rien piloter.

restart_fpm et php7.4-fpm en dur. Une tâche custom rechargeait php7.4-fpm après chaque déploiement. Logique tant que le serveur tournait en PHP 7.4. Après la migration vers PHP 8.1, cette tâche était non seulement inutile, elle était fausse — elle redémarrait un service PHP qui n’était plus celui servant l’application. Il a fallu retirer la définition de la tâche et son hook after(), les deux ensemble, sous peine de faire planter le déploiement sur une tâche fantôme.

Le chemin de recipe périmé. Le require 'recipe/symfony4.php' a dû devenir le recipe générique recipe/symfony.php de Deployer 7. Détail apparemment mineur, mais premier point de rupture classique d’une montée de version majeure.

Le ssh_multiplexing en aller-retour. Mis à false en Deployer 6 pour contourner un souci Windows, il a dû repasser à true pour Deployer 7 et son nouveau système de verrouillage. Une déclaration héritée d’un vieux bug, à inverser pour un bug nouveau.

deploy:lock / deploy:unlock, retirés carrément. Deployer 7 a un bug documenté où deploy:lock se redéclenche seul après deploy:writable, provoquant une GracefulShutdownException sur un déploiement pourtant sain. Comme je suis seule à déployer, j’ai retiré ces tâches de la liste explicite, en gardant le filet after('deploy:failed', 'deploy:unlock').

Ce qui me frappe : chacune de ces lignes avait été juste, un jour, pour une bonne raison. Aucune n’était une erreur de débutante. C’est exactement ça, la dette technique : pas du mauvais code, mais des décisions correctes qu’on n’a pas révisées quand leur contexte a changé.

Les migrations Doctrine : deux pièges de dépréciation coup sur coup

Le déploiement passait enfin la phase code, et calait sur la base de données. Deux problèmes distincts, tous deux liés à l’évolution de Doctrine Migrations.

Premier piège : la config du bundle. La syntaxe de doctrine-migrations-bundle avait changé. Les anciennes clés dir_name et namespace ont été remplacées par migrations_paths. Tant que la config n’était pas mise à jour, le bundle ne trouvait plus ses migrations correctement.

La vraie cause du 500, cachée derrière un fichier vide

Une fois Composer, Deployer et les migrations stabilisés, l’API se déployait — et plantait toujours en 500. Cause réelle : une variable CORS_ALLOW_ORIGIN manquante, bloquée par un .env.local.php vide sur le serveur, prioritaire sur le .env normal (comportement standard de Symfony : le fichier compilé prime, même vide). Un fichier de cache oublié par un ancien déploiement suffisait à masquer toute la config. Il a fallu aussi relancer OPcache après le réchauffement du cache, sinon le serveur continuait de servir l’ancienne version compilée.

Côté demo : biophp lui-même n’était pas épargné

Le site demo.amelayes-biophp.net avait sa propre saga. Des dump() dans les templates Twig faisaient planter la prod (remplacés par une macro tree maison). Plus profond : des objets biophp refusaient de se sérialiser, à cause de types non-nullables sur des getters pouvant renvoyer null selon le schéma Doctrine réel. Les types ont été alignés avec la base (v0.1.15 → v0.1.16), getSeqSet() a cessé de copier en tableau pour renvoyer son ArrayIterator d’origine, et plusieurs DataFixtures ont récupéré un : void de retour manquant. Le bundle EasyAdmin, jamais utilisé, a été retiré — encore une déclaration qui traînait pour rien.

La remise à plat de fond : Symfony 4.4 → 6.4, PHP 7.4 → 8.1

Restait le vrai sujet : le projet tournait encore en Symfony 4.4 et PHP 7.4, deux versions en fin de vie. Migration par paliers : 4.4 → 5.4 → 6.4 côté Symfony, 7.4 → 8.1 côté PHP, avec à chaque étape un audit à sec (composer update --dry-run) avant d’écrire quoi que ce soit — repérer les paquets qui changent, ceux qui refusent de se résoudre, et dans le code les fonctions dépréciées ou supprimées (each(), create_function(), propriétés dynamiques non déclarées). Un platform.php a été ajouté à composer.json pour figer la version PHP ciblée et éviter toute dérive. Au passage, découverte que le site demo tournait en réalité sur PHP 7.3 — pas 7.4 — à cause d’un SetHandler de vhost Apache resté sur l’ancienne version.

La fin : Migration vers PHP 8.5 et mise à jour de tout le composer vers la nouvelle version d’Api Platform

Deuxième piège : une migration qui plante sans rien casser. Voici le message qui m’a fait perdre du temps :

[bioapi-prod] [notice] Migrating up to DoctrineMigrations\Version20260807140000 [bioapi-prod] [warning] Migration … was executed but did not result in any SQL statements. [bioapi-prod] exit code 255 (Unknown error) ERROR: Task database:migrate failed!

Le comportement de doctrine/migrations a évolué : une migration dont le up() ne produit aucun SQL est désormais traitée strictement. Là où une ancienne version passait en silence, la nouvelle émet un warning et renvoie un code d’erreur 255 — ce qui fait échouer la tâche database:migrate de Deployer alors que, sur le fond, rien n’est cassé. Un classique de dette technique : ce n’est pas mon code qui a changé, c’est la sévérité de l’outil autour.

Le vrai fond du problème : array déprécié au profit de json. Sous ce warning se cachait une vraie migration de données. Le type de colonne Doctrine array — qui stocke via serialize() de PHP — a été déprécié puis abandonné au profit du type json. Les anciennes données sérialisées en base ne sont plus lisibles telles quelles par le nouveau type. J’ai donc dû modifier deux entités pour passer leurs propriétés concernées de array à json, et prévoir la conversion des données existantes. Encore une décision parfaitement valable à l’époque (le type array était l’usage courant) devenue une dette le jour où Doctrine a tourné la page.

Une fois que tout est ok, on y est ! Yalla !!! Pour le moment …

Ce que cette histoire dit de la dette technique

S’il faut retenir une chose : sur un projet perso laissé plusieurs mois, ce n’est presque jamais le code métier qui pourrit en premier. C’est l’écosystème autour — gestionnaire de paquets, outil de déploiement, version de PHP, un bundle oublié, une variable dans un fichier de cache, un type de colonne Doctrine — qui se désynchronise petit à petit, une décision correcte à la fois, jusqu’à ce que la dépréciation d’un seul maillon fasse tomber tous les autres.

Le deploy.php en est le symbole : chaque ligne avait une raison d’être, à un instant T, et il a fallu les relire une à une, des années plus tard, pour savoir lesquelles étaient encore vraies. C’est sans doute le vrai travail de fond de la maintenance : pas ajouter des fonctionnalités, mais se demander régulièrement si les décisions figées dans la config tiennent toujours.

La suite de ce chantier est déjà sur ma liste : cette fois-ci terminer pour de bon la librairie et enrichir le site de démo, avec les tests. Mais ça, c’est une autre histoire.

L’IA et moi

Il fallait bien que j’aborde le sujet : l’intelligence artificielle. Bouh le vilain mot ou pas. Tout est une question de nuances et d’usages.

Pour la petite histoire …

Il y a trois ans, un de mes amis me montrait un grand sourire aux lèvres ChatGPT, exalté, excité, porté aux nues, par la puissance de l’outil qui pouvait écrire du code à sa place. A ce moment là j’ai pensé à tous ces étudiants qui pouvaient faire faire leurs devoirs à leur IA, sans consommer un seul neurotransmetteur. Je ne voyais pas ça d’un très bon œil. Et puis ces machines là, un jour, est-ce qu’elles ne finiront pas par nous dominer ? Scénario catastrophe. Bon, je m’y suis inscrite par curiosité. Félicitations, vous venez de vous connecter à votre premier modèle de données.

Pourtant au travail, le sujet a commencé à poindre le bout de son nez. Mon gros client est vraiment un gros client que je chéris et une des collaboratrices a eu l’extrême sollicitude de faire à l’équipe de devs dont je fais partie un exposé sur l’impact positif de l’IA sur notre travail, avec des exemples, des modèles de données, tout ce qu’il faut pour bien avancer. J’étais restée bouche bée sur ce gain de temps. Résultat, nous nous y sommes tous mis. Parce qu’il faut bien le dire : les IA sont des assistants hors pair et je ne peux plus m’en passer. Car nous vivons une énorme révolution qui est bien supérieure à la révolution industrielle.

Mon coach de vie, Franck Nicolas, lors de son dernier séminaire, a consacré une après-midi entière à nous faire part de ses pensées sur le sujet. Vous savez que le monde va tellement vite qu’en 3 ANS seulement, oui 3 ANS, nos compétences deviennent obsolètes ? Ceux qui n’ont pas encore pris le train doivent le prendre, et vite. Car l’IA progresse, qu’on soit pour ou qu’on soit contre.

Et maintenant ?

J’utilise l’IA dans ma vie de tous les jours. Pas un usage abusif car je sais que :
1) La personne doit garder son libre arbitre sans basculer dans l’asservissement, comme ces gens qui demande à leur IA comment s’habiller ou pire, qui remplacent un partenaire par un robot. Si tu en es là, tu as un souci, désolée de te le dire.
2) L’utiliser à des fins utiles. n’oubliez jamais les ressources que ces IA consomment, les fakes et autres n’ont pas leur place ici.
3) Et puis il y a ceux qui ont abusé du pouvoir de l’IA sans censure, n’est-ce pas Elon ?
J’ai envie de dire, un peu comme les réseaux sociaux. Beaucoup de mauvais usages, pour un certain pourcentage de bons usages. Je vais rester positive et parler du dernier point (donc je ne parlerai pas de drones de guerre et compagnie).

Mes IA à moi

Claude

Forcément, je commence par lui, obligée. Claude est la quintessence de la puissance du travail de codeur. A condition de comprendre ce que tu lui demandes et que tu comprennes ce qu’il te répond. Parce que Claude, non seulement, il va chatter avec toi pour parler de code, mais aussi t’aider à résoudre tes problèmes de cybersécurité en te conseillant des outils à la pointe.
Claude Code (difficile à prononcer, ne trouvez-vous pas ?) analyse ton projet pour optimiser tes factorisations, te faire pointer du doigt ce que tu as salement programmé (ça nous arrive à tous) alors que tu es pris par le temps car rendre un travail propre est quand même primordial, ou t’aider à ressortir des vieux cartons ton projet perso mis de coté depuis 2019 (oui, je me remets sur BioPHP). Il peut aussi t’aider à faire des mods de builds pour Minetest, d’après un fichier 3D si tu ne te sens pas les capacités de faire un truc énorme (comme le vaisseau spatial qu’avait dessiné mon papa).
Mieux que ça, il peut créer des designs si c’est pas ton fort, et en plus si tu télécharges Workflow, il peut réorganiser tes arborescences si comme moi t’es un bordélique virtuel. Pour l’exemple, il m’a économisé 10 heures pour classer mes mails, chose que je n’avais pas faire depuis … longtemps.

Inconvénients ? ça peut être compromettant pour ta vie privée si tu utilises Workflow ou si tu l’utilises pour le tri des mails. Oui je sais la confidentialité, mais GMail connait déjà tout de ma vie …

ChatGPT

Le plus connu du public. En vrai, je l’aime bien.
Déjà je le consulte quand je me pose des questions sur certaines personnes, pourquoi réagissent-elles comme ceci ou comme cela, dresser un portrait psychologique, pour mieux appréhender la situation, trouver des solutions ou me rassurer, parce que je suis quelqu’un qui a besoin d’analyser et de comprendre sinon je tourne en boucle. Attention, il peut être trop gentil.
Mais je trouve que c’est le top du top des illustrateurs. Il faut toutefois bien le prompter et il peut faire des erreurs, mais les caricatures que je lui demande me font bien sourire et si je dois me baser sur des gens existants d’après leur photo il se débrouille pas trop mal.
Je ne l’ai pas poussé à fond, je connais des gens qui utilisent Codex et il est vraiment bien et il sait faire du webdesign bien soigné.

Inconvénients : Cependant … si je lui demande de m’écrire un texte fictif avec des situations données, il manque franchement de subtilité et d’imagination. L’humour et le décalage des situations n’est pas encore son fort si tu lui demandes d’écrire une histoire drôle. Et pour des questions particulièrement humaines, il manque encore cruellement de … d’un semblant d’empathie ?

Suno

Je gratte un peu de guitare, connais un peu de solfège, chante comme un rayon casseroles, rien de foufou, donc ne comptez pas sur moi pour composer.
Alors je m’amuse assez occasionnellement avec Suno, qui évolue vite et qui optimise de plus en plus la qualité de ses sons. S’il y a deux ans, la qualité auditive restait passable, on a aujourd’hui du mal à différencier avec une vraie chanson.

Les inconvénients : l’horreur de l’abus. Si des gens veulent faire carrière dans la musique, c’est important de composer et de jouer avec de l’humanité. Chanter avec sa vraie voix. Imaginez que le nombre de morceaux composés par IA DEPASSE LES 50% DU CATALOGUE SPOTIFY !!! Suno doit rester récréatif pour les amateurs dont je fais partie. Pitié … il faut régler ce problème ! Même si un son électronique peut sembler sympa, comme ce que j’ai pu écouter sur Radio Chirac, mentionner toujours que c’est de l’IA. Oui l’IA peut faire des sons très agréables, mais je préfère de loin écouter des légendes comme Queen ou les Stones et m’émerveiller des octaves de Freddy Mercury.

N’oublions pas les LLM locaux

On peut aussi bricoler pas mal de choses avec les LLMs. Un chatbot, ou alors des outils de « pentest » qui va discuter entre LLM pour savoir quoi en penser. Un sujet sur lequel j’aimerais bien me pencher une fois que j’aurai fait le tour de Claude.

Mon avis sur le reste

Je n’aime pas Canva. La génération des images est très moyenne (un avion trois ailes par exemple). Possible que cette plateforme ne soit pas adaptée à mes besoins.

Je n’ai ni testé Gemini, ni Grok, ou vu très vite fait mais qui n’apportent rien de plus à mes besoins déjà satisfaits.

Cependant, pour revenir au vaisseau spatial de mon père … j’ai été bluffée par le rendu 3D de Meshy. Voici pour l’exemple :
Le dessin :

Le fichier 3D pondu :

Un peu raté pour les ailes mais bon sang … je suis restée là aussi bouche bée car je ne m’attendais pas à tel résultat.

Et je cherche encore une IA bien faite qui puisse améliorer grandement certaines photos d’urbex que j’avais faites au smartphone car je n’avais pas de matériel ce jour-là. Les suggestions sont bienvenues.

Ma conclusion

Bien en fait, je n’ai pas encore tiré de conclusion pour être honnête.
L’IA est un outil tellement puissant, qui tire vers le haut tous les jours, les modèles se multiplient, tous plus performants les uns que les autres mais il faut garder tête froide. Comprendre les limites pour les humains que nous sommes.

Comme je le disais, mon avis est tout en nuances, il y a du très bon, du gain de productivité, de créativité, et aussi du gain de temps pour des taches qui nous paraissent rébarbatives.

Tout comme il est vrai je ne peux plus m’en passer. J’aime créer et me faire aider pour concrétiser ce que j’ai envie de concevoir. Du moment que je comprends et maîtrise ce que je fais.

Mais juste … il ne faut pas se faire remplacer. Tant qu’un robot humanoïde ne viendra pas vers moi pour me mettre un coup de pied, tout va bien, à mes yeux.

J’ai arrêté de faire mes pg_dump à la main (et ma base de 77 Go me dit merci)

Rappelez-vous, il y a quelques années, j’avais parlé de la migration de la base de mon jeu AIM sur PostgreSQL. C’était une bonne idée, mais je n’avais rien automatisé au niveau des sauvegardes. Donc je faisais régulièrement mes sauvegardes à la main, je coupais le jeu et hop, un bon dump qui prenait trois heures.

Puis j’ai fait le calcul du nombre de jours de données que je perdrais si le disque lâchait maintenant. Et j’ai arrêté de trouver ça drôle. Parce que perdre 15 jours de jeu, ça peut faire pleurer.

Voilà donc le récit de comment je suis passée du pg_dump artisanal à une vraie automatisation avec pgBackRest, ce que ça m’a appris sur les enjeux réels d’une sauvegarde, et surtout ce que tout ça coûte (ou pas) aux performances du SGBD.

Le problème du dump manuel : ce n’est pas une sauvegarde, c’est un souvenir

Commençons par le mythe à démonter. Beaucoup de gens (moi la première) pensent avoir une sauvegarde parce qu’ils ont ça quelque part :

pg_dump -U postgres mabase > /backup/mabase.sql

C’est un fichier. Ce n’est pas une stratégie. Voici pourquoi.

1. Le RPO est catastrophique

Le RPO (Recovery Point Objective), c’est la quantité de données que tu acceptes de perdre. Avec un dump manuel fait « de temps en temps », ton RPO c’est : depuis la dernière fois que j’y ai pensé. Ça peut être trois semaines. Et tu ne le sauras qu’au moment où ça comptera vraiment.

2. Un dump de 77 Go, ce n’est pas un fichier, c’est un événement

Ma base de prod fait environ 77 Go. Un pg_dump là-dessus, ce n’est pas une commande qu’on lance négligemment en journée : c’est une longue lecture logique de toute la base, un CPU qui part en compression, et un fichier énorme à écrire. Je vais y revenir dans la partie perfs, mais retenez déjà ceci : plus la base grossit, moins tu as envie de lancer ta sauvegarde à la main. Et donc moins tu la lances. Le manuel se sabote tout seul.

3. Tu ne peux pas remonter à hier 14h37

Le dump est une photo. Si ta dernière photo date de dimanche et que la bêtise a eu lieu mardi à 14h37, tu reviens à dimanche. Point. Toutes les données de lundi et mardi : perdues. Alors que PostgreSQL sait faire infiniment mieux — il écrit en permanence un journal de toutes ses modifications, les WAL (Write-Ahead Logs). Si on archive ces journaux, on peut rejouer l’histoire jusqu’à la minute près. C’est le PITR (Point-In-Time Recovery). Le dump manuel jette cette possibilité à la poubelle.

4. Une sauvegarde jamais restaurée n’existe pas

C’est le point qui fait le plus mal. Un dump dans un coin, dont tu n’as jamais vérifié qu’il se restaure, c’est un pari, pas une garantie. L’automatisation force à structurer ça : un dépôt, un inventaire, une commande de vérification.

Ce que j’ai mis en place : pgBackRest + archivage des WAL

J’ai choisi pgBackRest. Pas par snobisme d’outil, mais parce qu’il fait nativement les trois choses que je voulais : sauvegarde physique, archivage WAL, et rétention automatique.

Étape 1 — Autoriser l’archivage côté PostgreSQL

Dans postgresql.conf :

wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=mabase archive-push %p'
max_wal_senders = 3

Le point important ici : wal_level = replica est le minimum requis. Si vous laissez minimal, PostgreSQL refusera carrément de démarrer avec archive_mode = on. J’ai eu droit à ce joli message, un soir :

FATAL: WAL archival cannot be enabled when wal_level is "minimal"

Ça a le mérite d’être clair.

Étape 2 — Configurer la stanza

Une stanza, chez pgBackRest, c’est simplement le nom qu’on donne à un cluster sauvegardé. La mienne s’appelle mabase.

Dans /etc/pgbackrest.conf :

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
compress-type=lz4
process-max=4
 
[mabase]
pg1-path=/var/lib/postgresql/16/main

Trois choix à souligner :

  • compress-type=lz4 : nettement plus rapide que gzip pour un taux de compression très honnête. Sur 77 Go, la différence n’est pas cosmétique.
  • process-max=4 : pgBackRest parallélise. C’est un de ses gros avantages sur pg_dump, qui reste largement mono-thread sur ce type de travail.
  • repo1-retention-full=2 : je garde deux sauvegardes complètes, les vieilles s’effacent toutes seules. La rétention automatique, c’est la moitié de l’intérêt de l’automatisation. Sans elle, on remplace « oublier de sauvegarder » par « saturer le disque de sauvegardes ». J’ai vu des serveurs mourir de ça.

Étape 3 — Initialiser et vérifier

sudo -u postgres pgbackrest --stanza=mabase stanza-create
sudo -u postgres pgbackrest --stanza=mabase check

Le check est votre ami : il valide que l’archivage WAL fonctionne réellement de bout en bout. Ne sautez pas cette étape.

Étape 4 — Le cron (le cœur du sujet)

crontab -u postgres -e
0 2 * * 2 nice -n 10 pgbackrest --stanza=mabase --type=full backup

Traduction : tous les mardis à 2h du matin, sauvegarde complète, en priorité CPU basse.

Deux détails qui comptent :

  • Le cron appartient à l’utilisateur postgres, pas à root. C’est le bon niveau de privilège pour ce travail — inutile de faire tourner en root quelque chose qui n’en a pas besoin.
  • nice -n 10 : la sauvegarde s’exécute en priorité réduite. Si le serveur a autre chose à faire à 2h du matin, la sauvegarde s’efface poliment. On y revient tout de suite.

Et pour vérifier au réveil que tout s’est bien passé :

sudo -u postgres pgbackrest --stanza=mabase info

Et les performances du SGBD dans tout ça ?

C’est LA question qui m’a fait traîner des mois. « Si j’automatise, est-ce que je vais plomber ma base ? »

Réponse courte : le manuel coûte plus cher que l’automatique. Voici pourquoi.

pg_dump est une lecture logique, pgBackRest une copie physique

pg_dump ne copie pas des fichiers : il reconstruit la base en la relisant intégralement et en générant du SQL. Ça veut dire un parcours complet, du CPU en pagaille, et surtout une transaction très longue ouverte pendant toute l’opération. Or une transaction longue empêche l’autovacuum de nettoyer les lignes mortes derrière elle. Sur une base à fortes écritures, un dump interminable en pleine journée, c’est du bloat qui s’accumule et des perfs qui se dégradent — bien après la fin du dump.

pgBackRest, lui, copie les fichiers du cluster. C’est plus proche du disque, ça se parallélise, et ça n’a pas ce coût transactionnel.

Le vrai chiffre

Ma première sauvegarde complète des 77 Go, avec lz4 et nice -n 10, a pris 22 minutes. Vingt-deux minutes, à 2h du matin, en priorité basse, sans que personne ne s’en aperçoive. À comparer avec un dump équivalent lancé un mardi à 15h « parce que j’y ai pensé ».

Le coût continu de l’archivage WAL

L’archivage n’est pas gratuit : chaque segment WAL rempli déclenche un archive-push. Le coût unitaire est faible, mais il y a un piège à connaître : si l’archive_command est plus lente que le rythme de production des WAL, les segments s’accumulent dans pg_wal/ et le disque se remplit. Surveillez cet espace disque. C’est le principal effet de bord d’une config PITR, et il est silencieux jusqu’au moment où il ne l’est plus.

Un mot sur synchronous_commit

Sur des charges à écritures très fréquentes, synchronous_commit = off donne un gain net : PostgreSQL n’attend plus la confirmation d’écriture du WAL sur disque pour valider la transaction. Mais soyons précises sur ce qu’on échange : en cas de crash brutal, vous perdez les quelques dernières centaines de millisecondes de transactions validées. La base reste cohérente (ce n’est pas fsync = off, qui lui est un vrai danger en prod), mais elle n’est pas complète.

C’est un arbitrage à faire en conscience, selon la valeur de vos dernières millisecondes.

Le jour où ça plante : restaurer à mardi 14h37

Tout ce qui précède ne sert à rien si on ne sait pas s’en servir le jour J. Alors imaginons le scénario. Mardi, 14h37, quelqu’un lance un DELETE sans WHERE sur une table centrale. À 14h50, on s’en aperçoit. Objectif : remettre la base exactement dans l’état de 14h36.

0. Ne rien faire de brutal

Le premier réflexe est le plus important : on ne redémarre pas PostgreSQL, on ne bricole rien. Si la base tourne encore, on l’arrête proprement et on réfléchit. Les WAL déjà archivés sont votre matière première : ne les touchez pas.

1. Regarder ce dont on dispose

sudo -u postgres pgbackrest --stanza=mabase info

Vous obtenez la liste des sauvegardes complètes avec leurs dates de début et de fin. Le point à vérifier absolument : votre cible (mardi 14h36) doit être postérieure à la fin d’une sauvegarde complète, et tous les WAL entre cette sauvegarde et la cible doivent être présents dans l’archive. Dans mon cas, avec un full le mardi à 2h, une cible à 14h36 le même mardi est parfaitement atteignable : pgBackRest repart du backup de 2h et rejoue ~12h de WAL.

2. Arrêter PostgreSQL

sudo systemctl stop postgresql

3. Restaurer avec une cible temporelle

C’est ici que le PITR prend tout son sens :

sudo -u postgres pgbackrest \
  --stanza=mabase \
  --delta \
  --type=time \
  --target="2026-07-14 14:36:00+02" \
  --target-action=promote \
  restore

Décortiquons, parce que chaque option compte :

  • –type=time + –target : la date et l’heure exactes où l’on veut atterrir. Précisez le fuseau horaire (+02 ici) — sans lui, PostgreSQL interprète selon le timezone du serveur, et se tromper d’une heure sur un rollback, c’est ballot.
  • –delta : pgBackRest compare les fichiers existants et ne réécrit que ce qui diffère. C’est plus rapide, et surtout ça vous évite d’avoir à vider le répertoire de données à la main. Parce que oui, la méthode « officielle » sans –delta exige un data directory vide, et ça veut dire taper un rm -rf /var/lib/postgresql/16/main/* en tremblant à 15h un mardi. Utilisez –delta.
  • –target-action=promote : une fois la cible atteinte, PostgreSQL sort du mode recovery et redevient ouvert en écriture. L’alternative, –target-action=pause, arrête la relecture et attend : la base est lisible mais figée, ce qui permet de vérifier qu’on est bien au bon endroit avant de valider. Sur une restauration où j’ai un doute sur l’heure exacte, je commence par pause.

pgBackRest choisit tout seul la bonne sauvegarde complète à utiliser en fonction de la cible. Il écrit également le recovery.signal et le restore_command dans postgresql.auto.conf — inutile de les créer à la main.

4. Redémarrer et regarder la base rejouer l’histoire

sudo systemctl start postgresql
sudo journalctl -u postgresql -f

C’est le moment le plus étrange de l’opération : PostgreSQL rejoue les WAL un par un, et vous voyez défiler dans les logs les heures de votre journée à l’envers. Vous cherchez la ligne qui confirme que le point de recovery a été atteint (recovery stopping before commit of transaction…, puis database system is ready to accept connections).

Tant que le recovery tourne, la base est en lecture seule. C’est normal, laissez-la finir.

5. Vérifier avant de crier victoire

La donnée la plus récente doit dater de ~14h36. Si oui : c’est gagné, et vous venez de récupérer 12h de travail qu’un pg_dump du dimanche vous aurait fait perdre.

SELECT COUNT(*) FROM ma_table_massacree;
SELECT MAX(created_at) FROM ma_table_massacree;

Pour conclure

Voilà tout tourne en tâche de fond, et les joueurs et moi on n’a plus à s’en soucier et au lieu de se préoccuper des dumps on peut ainsi écouter Radio Chirac, un son qui déchire pas mal.

Sommeil créatif

En ce moment, il m’arrive quelque chose d’assez extraordinaire.

Je ne sais pas pourquoi, je ne sais pas comment, peut-être la multiplication d’activités ludiques et créatrices qui auraient stimulé une zone du cerveau … ou crée de nouvelles connexions.

Quand je me réveille de ma nuit ou de ma sieste sacrée de 13 heures, je me retrouve une fois sur deux avec une mélodie dans la tête. Pas une chanson que je connais, pas une chanson qui a existé. Non … une mélodie, une suite d’accords, un rythme parfaitement cohérent et non discordant que mon esprit a entièrement créée de toutes pièces !!!

Un peu de bio …

Comme vous le savez certainement, la nuit, le cerveau ne se met pas vraiment en pause. Il passe en mode “atelier”.

Pendant le sommeil paradoxal (aussi appelé phase REM), le corps est presque immobile, mais le cerveau, lui, est très actif. C’est le moment des rêves.

Et c’est aussi là que peuvent apparaître des choses étonnantes. J’ai déjà trouvé des solutions à des problématiques de programmation après une bonne nuit. Mais maintenant, s’ajoutent aussi des mélodies que j’ai l’impression d’entendre alors qu’elles n’existent pas.

En réalité, le cerveau ne “crée” pas à partir de rien. Il prend des morceaux de ce que qu’il déjà vécu : des sons entendus dans la journée, des musiques oubliées, des rythmes captés sans faire attention. Tout ça est stocké quelque part, même si on ne s’en souvient pas.

Pendant le sommeil paradoxal, il mélange tout ça un peu librement. Il assemble, teste, recolle autrement. Comme un DJ qui ferait des remix sans prévenir. Le coquinou.

Le comble

Bien, pour quelqu’un qui saurait chanter et composer, ce serait une matière de travail passionnante. Mais, je ne sais pas chanter, même en ayant pris des cours.

Heureusement nous sommes en 2026 et nous avons des outils, et j’ai le sens du rythme, quelques notions de solfège, au moins ça.

Prenons l’exemple de cette nuit, je me réveille avec un air rythmé : tata-tata-tata-tata taaaaa (musicalement on dirait croche-croche croche-croche croche-croche noire). Le refrain, lui (je rêve de bribes de mélodies) … était somme toute … répétitif, avec une montée sur chaque vers :

You give me something
You give me something
You give me something
Yeaaaaaaaah

La solution de 2026

J’en parle donc à ChatGPT (je vous ferai prochainement un article sur les IA que j’utilise, et un autre sur mon avis perso) qui me sauve, à peu près, mais en retient l’essentiel. Il me fait une grille d’accords d’après mes fredonnements approximatifs :

X:1
T:You Give Me Something (motif reconstruit)
M:4/4
L:1/8
Q:1/4=90
K:C

G G G G | G G G G | A A G E | G4 |
G G G G | G G G G | A A G E | G4 |
G G G G | G G G E | F F E D | E4 |
G G G G | G G G G | A A G E | G4 |
G G G G | G G G G | A A G E | G4 |
G G G G | G G G G | A A G E | G4 |
G G G G | G G G G | G G G G | C4 |

Il m’a transcrit ça en anglais :
– G = sol
– A = la
– E = mi
– F = fa
– D = ré

Je connais assez Suno, j’ai déjà crée des musiques et des chansons, pour m’amuser et créer du lore pour mon jeu Minerland. Jusque là, ça restait une récréation.

Je prompte donc Suno, et me voici donc avec … quelque chose qui se rapproche de ce que j’ai rêvé … sans les paroles, mais je vois à quel moment inclure les « You give me something » que j’ai imaginés … Qui sait … peut-être qu’un jour ça me servira à faire quelque chose d’intéressant …

Sur ce, faites de beaux rêves !

De la cybersécurité (I’m back. Stronger.)

Enfin j’ai trouvé un peu de temps pour réparer tout mon bourbier.

En effet, depuis 2024, quand on accédait à mes sites wordpress, vous aviez ce message d’accueil fort charmant qui mentionnait un « incident technique ». J’avais dû fermer mes trois sites wordpress …

Pas des moindres. J’avais été piratée de partout ! Mon site d’urbex par exemple redirigeait vers une boutique en ligne. Et paf la cascade, mon site vitrine, mon blog et même un temps mon wiki sur mon jeu Minerland ! Un peu comme un jeu de dominos qu’on fait tomber petit à petit … de quoi être parano.

Il aura fallu attendre 2024 pour que ça se produise, en sachant que mes premiers sites perso remontent à 2000. Depuis, je me disais, tranquille, que je n’avais pas de raisons de me méfier ni de consolider mes iptables bien comme il le faut … voire faire l’impasse sur les mises à jour. L’erreur fatale. La cybersécurité est devenue lame de plus du développeur web qui doit apprendre de ses erreurs.

Intro sur la cybersécurité

En 2026, les petits sites web sont plus que jamais en première ligne.

Les attaques les plus courantes contre les petits sites sont silencieuses, opportunistes et automatisées. Elles défigurent un site, volent des données clients, ou utilisent le serveur pour héberger des contenus illicites, le tout à l’insu du propriétaire.

La grande nouveauté de 2026, c’est l’utilisation de l’IA par les attaquants. Les agents IA autonomes deviennent des outils courants de la cybercriminalité, capables de cartographier une attaque en quelques minutes et de générer des campagnes de phishing ciblées à grande échelle. Les campagnes de phishing générées par IA sont désormais quasiment indétectables — fini les fautes d’orthographe et les formulations bancales.

Plus de 90 % des piratages de sites WordPress exploitent des failles déjà corrigées dans une mise à jour que l’administrateur n’a pas appliquée. Le message est clair : mettre à jour, sécuriser ses accès, surveiller ses logs — ce n’est plus optionnel, même pour un petit blog perso.

Acte I — La découverte

Tout a commencé par un constat simple : mes sites WordPress ne répondaient plus correctement. En fouillant, j’ai découvert l’ampleur des dégâts. Les attaquants avaient réussi à s’introduire dans mes trois sites WordPress et ils s’étaient fait plaisir.

Leur spécialité : injecter du contenu. Des pages de spam, du phishing, et le pompon — un site de commerce en ligne complet, hébergé à mes frais sur mon propre serveur. Sympa.

En analysant les bases de données, j’ai retrouvé leurs traces partout. Dans la base d’amelieonline.net, un webshell — un script PHP qui permet de prendre le contrôle d’un serveur à distance — était planqué dans le fichier functions.php du thème. Du code obfusqué en base64 qui se connectait à des serveurs distants pour exécuter des commandes. Le plugin de sécurité All-In-One Security l’avait détecté et mis en quarantaine, mais le mal était fait.

Dans les fichiers du serveur, les bots avaient déposé des scripts PHP aux noms discrets : x.php, ha.php, gg.php… Des portes dérobées qui leur permettaient de revenir à volonté, même après un changement de mot de passe.

Acte II — Comment ils sont rentrés

La réponse est aussi simple que gênante : mon mot de passe wordpress était devenu trop faible. Ou alors ils se sont fait une joie de l’absence de certificat ssl …

Les bots qui parcourent internet 24h/24 testent des millions de combinaisons sur /wp-login.php et xmlrpc.php (une porte d’entrée WordPress souvent oubliée). Avec un mot de passe simple, il leur faut parfois quelques heures pour entrer.

Mais ce n’est pas tout. Mon serveur cumulait les facteurs aggravants. Ubuntu 18.04 en fin de vie depuis avril 2023, donc plus aucun correctif de sécurité. PHP 7.x, qui n’est plus maintenu depuis fin 2022. Pas de HTTPS — ce qui signifie que chaque fois que je me connectais à l’admin WordPress, mon identifiant et mon mot de passe transitaient en clair sur le réseau. Dans un café, à la gare, à l’hôtel, n’importe qui sur le même Wi-Fi pouvait les intercepter avec un simple outil comme Wireshark.

Et mon certificat SSL ? Expiré depuis des mois. J’avais payé cher pour un certificat classique, il avait expiré, et je n’avais jamais pris le temps de le renouveler. J’étais persuadée qu’il fallait racheter un certificat pour chaque nom de domaine. Trois domaines, trois certificats, une facture qui pique. En fait, non — mais j’y reviendrai.

Acte III — Le grand nettoyage

Le ménage a été méthodique. D’abord, les bases de données : analyser chaque dump SQL à la recherche de contenu injecté — du spam en chinois, en japonais, en cyrillique, des liens vers des boutiques frauduleuses, des webshells en quarantaine. Chaque site a été passé au peigne fin, table par table, grâce à l’aide de mon ami Claude, devenu mon nouveau formateur/secrétaire/IA couteau suisse.

Ensuite, les fichiers du serveur : traquer les scripts PHP malveillants dans les répertoires d’uploads (il ne devrait jamais y avoir de fichier PHP dans wp-content/uploads/), vérifier chaque thème, chaque plugin, identifier les fichiers modifiés récemment.

Et puis la grosse opération : migrer le serveur d’Ubuntu 18.04 vers une version maintenue. Trois sauts successifs — 18.04 vers 20.04, puis 22.04 — chacun avec son lot de surprises. PHP 7 vers PHP 8 a cassé plusieurs choses : des fonctions dépréciées, des syntaxes devenues invalides, des conflits de configuration entre l’ancien PHP-FPM et le nouveau module. À chaque étape, un site qui tombe, un diagnostic, une correction, on repart.

Acte IV — L’horreur des logs

C’est une fois le serveur remis d’aplomb que j’ai vraiment mesuré l’ampleur du problème. En regardant les logs d’authentification SSH :

Failed password for root from 179.111.150.107
Failed password for invalid user adurbex from 172.188.89.41
Failed password for invalid user amelayesbiophp from 59.51.98.254
Failed password for invalid user urbexmarseille from 187.191.48.4
Failed password for invalid user tonwebautableau from 121.78.158.30

Des dizaines de tentatives par heure. Et le plus flippant : les bots n’essayaient pas que des noms génériques comme « admin » ou « root ». Ils testaient adurbex, urbexmarseille, amelayesbiophp etc … — des identifiants dérivés de mes noms de domaines, de mon pseudo, de mes projets.

Quelqu’un — ou plutôt quelque chose — avait scanné mes sites, relevé tous les indices disponibles. Les noms d’auteur WordPress sont exposés par défaut via /?author=1 ou l’API REST (/wp-json/wp/v2/users). Les pages « à propos », les footers, les noms de domaine eux-mêmes : tout est découpé, recombiné, et testé automatiquement.

Les logs Apache racontaient la même histoire côté web : des scans massifs de wlwmanifest.xml (un fichier WordPress utilisé pour détecter les installations), des rafales de requêtes cherchant des webshells PHP à des noms comme x.php, ha.php, gg.php… Un bot a généré des dizaines de 404 en quelques millisecondes, balayant méthodiquement tous les noms de fichiers suspects.

En analysant les adresses IP, un inventaire géographique impressionnant : Brésil, Bulgarie, Chine, Corée du Sud, Russie, Vietnam, Pays-Bas, Ukraine, Singapour, Afrique du Sud… La plupart provenaient de datacenters ou de services cloud comme Microsoft Azure ou Alibaba Cloud. Et l’ironie : l’une des IP attaquantes appartenait à un serveur Kimsufi OVH — un serveur dédié comme le mien, probablement compromis et utilisé comme relais.

Ce ne sont pas de vrais humains derrière un écran. Ce sont des botnets — des réseaux de milliers de machines compromises qui scannent automatiquement toutes les IP du monde, 24 heures sur 24.

Acte V — Pourquoi mon petit serveur ?

C’est la question que je me suis posée. Mes sites ne contiennent rien de sensible. Mais ce n’est pas mes données qui intéressent les attaquants. C’est mon serveur lui-même : sa bande passante pour lancer des attaques vers d’autres cibles ou participer à des attaques DDoS, son processeur pour miner de la cryptomonnaie, son adresse IP pour héberger du phishing ou envoyer des millions de spams, et le fait qu’il tourne 24h/24 en faisant office d’outil gratuit.

Un serveur dédié compromis devient un soldat anonyme dans une armée de machines zombies. Et quand quelqu’un remonte la piste d’une attaque, c’est sur mon Kimsufi qu’il tombe — pas sur le vrai attaquant.

Acte VI — La fortification

La reconstruction s’est faite couche par couche.

Fail2ban, valeur sûre. J’avais fail2ban d’installé, mais sa configuration par défaut était une passoire : 10 minutes de bannissement après 5 échecs. Les bots attendaient tranquillement et revenaient. 4681 tentatives échouées au compteur, 491 IP bannies au total, mais zéro bannie à l’instant T. J’ai durci la config : 3 échecs en une heure, et c’est 24 heures de ban.

Mais le SSH n’était pas le seul front. J’ai ajouté des jails fail2ban pour chaque type d’attaque : les scans WordPress (wlwmanifest), les floods de 404 génériques, les tentatives de brute force sur DokuWiki, les scans de fichiers sensibles. Six jails au total, chacune avec ses propres seuils. Le port 22 quant à lui, exit !

Iptables pour les récidivistes. Pour les IP les plus agressives — celles avec 60, 80, 90 tentatives au compteur — j’ai écrit un script qui les bloque définitivement dans iptables. Ces adresses ne peuvent plus du tout communiquer avec mon serveur, sur aucun port, par aucun protocole.

CrowdSec, la défense collaborative. En plus de fail2ban, j’ai installé CrowdSec — un outil communautaire où les serveurs partagent les IP malveillantes. Quand une IP attaque un serveur du réseau, elle est signalée et bloquée sur tous les autres.

HTTPS avec Let’s Encrypt. Fini les certificats payants. Certbot et Let’s Encrypt m’ont permis de sécuriser mes trois domaines en une seule commande, gratuitement, avec renouvellement automatique tous les 90 jours. Plus jamais de certificat expiré oublié dans un coin. Un timer systemd vérifie deux fois par jour si un renouvellement est nécessaire.

Le blocage de xmlrpc.php. Ce fichier WordPress est un vecteur classique de brute force. Bloqué.

Les permissions qui vont bien. 644 pour les fichiers, 755 pour wp-content.

La mise à jour de tout. Ubuntu à jour, PHP à jour, WordPress core à jour, plugins à jour, thèmes à jour. Chaque composant obsolète est une porte ouverte.

Ce que j’ai appris

Cette aventure m’a enseigné des leçons que j’aurais aimé connaître plus tôt.

Un mot de passe faible est une porte ouverte. C’est banal à dire, mais c’est la cause numéro un des compromissions WordPress. Aujourd’hui, 20 caractères minimum, générés aléatoirement, et uniques pour chaque site.

Le HTTPS n’est pas optionnel. Même pour un blog perso, chaque page de connexion sans HTTPS est une invitation au vol d’identifiants. Et avec Let’s Encrypt, il n’y a plus aucune excuse financière.

La sécurité par défaut n’existe pas. Fail2ban installé avec sa config d’usine, c’est presque comme s’il n’était pas là. Il faut prendre le temps de configurer chaque outil correctement.

Tout serveur exposé sur internet est une cible. Ce n’est pas une question de « si », mais de « quand ». Les bots ne dorment jamais, et ils sont plus malins qu’on ne le croit — ils analysent vos sites pour en extraire des identifiants potentiels. Les premières tentatives de brute force arrivent dans les minutes qui suivent la mise en ligne d’un serveur.

Un système non maintenu est un système compromis. Ubuntu 18.04 en fin de vie + PHP 7 abandonné = zéro correctif de sécurité depuis des mois. Autant laisser la porte grande ouverte.

Vérifiez vos logs régulièrement. Sans cette habitude, je n’aurais jamais su que mon serveur subissait des milliers de tentatives d’intrusion quotidiennes.

Rien ne dure.

Ces mots martèlent sans arrêt mon crâne, rien ne dure, personne n’est irremplaçable. Mon meilleur ami en est l’auteur original, voulant nous rassurer que la vie en était ainsi, tourmentée de rivières agitées, et que ces eaux se renouvellent sans arrêt.

Un samedi comme un autre, ma mère et ma sœur sont chez moi, nous savourons l’instant présent autour d’un apéritif, étais-je loin de me douter que la Grande Horloge tournait ? Elle tourne, tourne inlassablement, parfois d’une lenteur accablante, parfois d’une rapidité déconcertante. Et à ce moment, là, je n’entendais pas ce tic-tac effroyable. Un tic-tac qui allait bientôt s’arrêter pour quelqu’un.

Ces dernières années, j’ai vu beaucoup de gens partir, des horloges arrêtées, des amis, de la famille, des connaissances, beaucoup trop de départs qui vous mettent au pied du mur.

Rien ne dure.

Nous naissons, nous grandissons, nous évoluons, nous réussissons, nous échouons, nous vieillissons, nous mûrissons, nous expérimentons ce grand manège qu’est la Vie. Nous la chérissons, cette vie, parfois nous la maudissons. Nous nous exerçons à la chasse au Temps, ne voulant pas écouter les aiguilles qui parfois sont trop bruyantes ou trop silencieuses.

Parfois, nous profitons de l’Instant Présent, nous plaisantons, sommes dans la douceur d’un moment joyeux, et puis, d’une seconde à l’autre tout change. Une pause dans ma bulle, un SMS, la violence d’un message qui vous gifle comme jamais, et vous laisse KO, en état de choc. Appuyée contre le mur, les jambes coupées, assise par terre, appelant la clinique. Le cerveau ne répondant plus, le choc coupant les connexions du cerveau limbique.

Mon père venait de décéder.

Un état de non-retour, un état inaliénable, intransigeant, irrévocable. Le temps détruit tout. Rien ne sera plus comme avant. Pourtant, connaissant son âge, je commençais à me préparer à l’inéluctable. Mais en vérité, nous ne sommes jamais prêts.

Rien ne dure. Mais certaines personnes sont irremplaçables. Un parent, on en a qu’un dans la Vie. Parfois, en tant qu’enfant, on le chérit, on le maudit, on aurait volontiers échangé des places, je ne vais pas approfondir cette partie personnelle, le reste nous appartient à lui et moi. Mais on n’a qu’un père, tel qu’il est.

On se retrouve dans un torrent d’émotions, un cheminement du Deuil, ce Styx à traverser, et que je connaissais déjà … le choc, le déni, la colère, la dépression, l’acceptation, tout cela décuplé, le tout parsemé d’une lourde procédure administrative qu’on voudrait aussi courte que possible. On voudrait que tout soit une farce, une mauvaise blague de sa part. Mais non, il était bien parti, emportant avec lui une partie de moi.

On repasse en arrière le film de sa vie, on regarde des photos, des petits films où il était si vivant, un grand sourire aux lèvres. Quand je suis dans sa maison, je m’attends à le voir surgir, ravi « je t’ai préparé une daube ma puce, tu vas te ré-ga-ler !!! ».

On ne profite jamais assez de ces instants, pourtant si banals à priori … le regarder préparer de savoureux repas pour mieux les partager, regarder un film en sa compagnie car il adorait le cinéma, se promener au bord du lac … Il me disait « La vie est un beau film qui se termine mal. ». Il était nerveux de nature, mais si dénué d’anxiété, voyant les choses telles qu’elle étaient mais pas pire, et comme j’ai pu lui envier cette qualité de vivre la vie sans craindre le lendemain, faire des scénarios alambiqués qui font monter le rythme cardiaque et parsemer les nuits d’yeux grands ouverts. A la fin, nous sommes tous logés à la même enseigne, un aller sans retour, ticket simple.

On part, dénué de tout bien matériel, de tout argent, emportant avec soi ses actes, ses pensées, ses missions de vie. On ne laisse que le souvenir de sa présence, en bas, chez les vivants, qui se questionnent. Quand viendra « mon tour » ? Et que se passera-t-il quand la Faucheuse m’aura envoyée en voyage forcé ? Qu’emporterai-je ? Que laisserai-je ?

Je voudrais que l’Univers / Dieu / whatever m’aide à trouver ce Chemin de Vie qui pourra me permettre de donner le meilleur de moi-même, me dire, oui la vie est un beau film qui se terminera mal pour ceux et celles qui m’auront aimée. Je voudrais continuer à frissonner en urbex, donner du positif aux gens, que la vie me donne ce dont j’ai besoin mais pas plus, me retrouver prête à enfin rencontrer l’Amour qui me correspond, voyager, découvrir, expérimenter. Devenir sage et spirituelle, une bonne personne qui toutefois sait dire ses limites, relativiser, prendre du recul. Réaliser par exemple que remplir sa déclaration d’impôts ne vaut pas quinze nuits blanches.

Juste de quoi me dire, à ma dernière seconde « c’était quand même un bon film ».

Nous sommes dans une Société qui veut que nous ayons peur de la Mort, quitte à bannir ce mot des réseaux sociaux …
Nous voulons tant la chasser, provocant des hystéries collectives, des folies générales et protections fallacieuses : « Nous sommes en guerre !!! La Mort tue !!! ».
Parce qu’Elle est là, et fait partie de la Vie. Elle viendra quand même un jour arrêter votre Montre, non pas votre dernière « Smartwatch » qui finira à la poubelle dans 5 ans ou sera dérobée par un individu sans scrupule, mais celle qui vous accompagne depuis toujours, la Votre, qu’on ne pourra jamais voler.

Rien ne dure.

J’ai testé pour vous : l’Italie !!!

Depuis le temps que l’idée me trottait dans la tête, d’autant plus que le pays regorge de magnifiques spots urbex … j’ai fini par me laisser tenter. Laissez-vous guider dans ce premier trip qui ne sera pas le dernier. L’Italie ça se savoure plus d’une semaine. D’ailleurs à propos de savourer …

La gastronomie : OUI, OUI et OUI !

La gourmande que je suis sait qu’elle va dans un pays dont la réputation n’est plus à faire. Je me suis fait une raison au Royaume-Uni (on n’y va pas pour ça, certainement pas, quoique le saumon d’Ecosse est à si bas prix que c’est un crime de s’en priver). J’ai été intriguée positivement par l’Allemagne, déçue par la Tchéquie qui vous concocte des plats trop bourratifs. Mais là on est en Italie. Les pâtes, la pizza sont des valeurs sûres. Les gelati, rien de mieux pour satisfaire un petit creux. Pour les amateurs de vins, le Chianti et le Prosecco sauront amadouer vos papilles. Mais vous découvrirez aussi les caloni, les suppi et autres arancini … Même en détestant le fromage, je n’ai pas hésité à ajouter du parmesan sur mes macaroni !!! Mama miaaaaaa !

Le lèche-vitrines en Italie, où tu as vraiment envie de lécher la vitrine !

Milan : NON, NON et NON.

Milan, c’est la grosse métropole bien corsée, pire que Paris. Nid à touristes bien condensés, c’est compliqué. Les cars de visite sont même les plus désorganisés que je n’ai jamais vus.
Les autochtones y sont revêches, peu avenants, pas souriants.
Les restaurants vous font payer une fortune, et y ajoutent volontiers par-ci par là des taxes venues d’on ne sait où.
Visiter la cathédrale « El Duomo » est un parcours du combattant et on n’est pas mécontent de quitter la ville. Qui a du potentiel, une beauté sûre, mais tout cela est gâché par une agitation permanente. La seule raison pour laquelle j’ai voulu y aller, était pour l’urbex. Vous y trouverez des spots de choix. Mais n’y passez pas votre vie.
Veni, vidi, vici … Arrivederci Milano.

ça grouille, impossible de faire une belle photo.

Rome : Un autre univers …

Ma maman me dit toujours qu’à ses yeux Rome est la plus belle ville du monde, et en parle avec les yeux qui brillent. J’allais tester ça !

Un peu frileuse en embarquant dans le train, pour le coup, je ne voulais pas être déçue. Mais c’est une toute autre atmosphère qui vous attend. Arrivée à Rome, je me promène un peu dans la gare, et ses stands gastronomiques qui n’hésitent pas à vous faire goûter leurs produits. Vous avez déjà un avant-gout de ce qui vous attend : vous allez vous ré-ga-ler !

Rome a beaucoup moins ce côté métropole, et pour cause, le centre-ville est parsemé par-ci par là de ruines historiques qui lui donne ce charme tellement typique de la Dolce Vita.

Déjà, les habitants sont beaucoup plus chaleureux. Vraiment, promenez-vous, voire perdez-vous, dans les petites ruelles où les maisons sont orangées, ça sent bon les fleurs et les bons petits plats. Et regardez les gens, ils se voient, ils crient leur amitié et se serrent dans les bras ! On est obligé de visiter avec le sourire, tout est prétexte à la bonne humeur, à l’émerveillement (à part le métro).

Rien à dire, c’est beau. Majestueux. Bellissimo.

N’hésitez pas à vous promener dans le Vieux Rome de nuit, côté Colisée / Forum, c’est tellement magnifique que j’en ai eu les larmes aux yeux, vraiment, j’ai pleuré d’émotion. C’est doux, c’est beau, on s’y sent en sécurité, même en étant une femme seule. C’est la Dolce Vita à l’état pur !

Niveau gastronomie, on retrouve des prix raisonnables. Les restaurants sont bons marché. La pizza est surprenante quand on la compare à celles de chez nous. Elles sont toutes fines, simples, sans chichis, de la tomate, un accompagnement, du fromage, et basta ! Mais molto bene …

Buon appetito !!! (Pizza aux pepperoni)

Certains restaurants optent pour l’originalité dans leur design :

Bien entendu, on ne peut visiter Rome sans faire un tour à la Cité du Vatican et au Colisée, ainsi que le Forum, et je ne peux vous recommander que d’utiliser des billets coupe-file car il y a vraiment du monde. Et optez pour des visites guidées pour compléter vos notions d’Histoire. Et y aller tôt le matin, c’est mieux ! Message aux ochlophobes (dont je fais partie) : la Chapelle Sixtine est somptueuse mais oppressante de par la foule, les consignes y sont strictes qui plus est, préparez-vous à dompter votre stress.

Il y a des quartiers où il convient de ne pas circuler après 11 heures, comme du côté du Panthéon, rabattez-vous plutôt dans un des nombreux parcs, qui sont d’une beauté phénoménale (allez jeter un œil au jardin botanique, surtout l’été). Car Rome est immense, vous allez marcher, marcher, pendant des heures, ce qui va vous aider à éliminer les calories de vos pizzas et de vos macaroni al ragu, ce qui tombe bien, car vous n’aurez pas de surprise sur la balance à votre retour (véridique).

Une surprise m’a attendue à la fin du séjour : un trolleybus en gare de Roma Termini.

Mon avis global

Milan, non, vous l’avez compris. Mais Rome m’a enchantée. Il y a tellement de choses à y voir que j’ai manqué beaucoup d’endroits. J’ai eu un pincement au cœur en quittant la ville, mais j’y reviendrai lors d’un prochain trip, qui inclura surement Florence et Venise.
J’ai été tellement conquise que je me suis lancée dans une reproduction du Colisée dans mon serveur Minetest …

Je déclare la guerre aux « lol » !!!

Il fut un temps où je fréquentais les sites de rencontres, cultivant à l’époque l’espoir d’y rencontrer une princesse de contes de fées.

Dans ce contexte, je faisais vite le tri … lire des fautes à chaque mot, désolée je ne peux plus. J’ai déjà eu des histoires avec des gens qui n’étaient pas doués en orthographe, mais j’ai vite fait la corrélation. Ce n’est pas une question d’ouverture d’esprit, car l’ouverture je la faisais, me disant que l’autre avait certainement des qualités qui pouvaient me plaire, mais ces personnes n’étaient pas faites pour moi : impossible de parler de culture, des choses qui me passionnaient, de faire des débats … blocage complet. Les « cc sa va ? » … impossible également.

Bien sûr, il y a des gens qui peuvent être atteints de dyslexie », et autres « dys-« , mais si on va par là, 70% des gens avec qui je communiquais étaient donc atteints d’un trouble ? Je ne suis pas d’accord.

Il faut que je vous avoue quelque chose : je suis phobique des fautes d’orthographe, oui je suis une « pédante grammaticale » assumée, et voir des « er » à la place des « é » ou des « ez » à la place des « er », je ne comprends pas ce qu’il se passe dans cette logique. Et quand je ne comprends pas, ça m’énerve. Pourtant des fautes, j’en fais, et je me suis rendue compte de mes limites lors de mes actuelles révisions pour le « Certificat Voltaire » que je prépare. Ou alors je fourre par-ci par-là quelques fautes d’inattention. Mais les grosses fautes, les crimes contre la langue de Molière comme les « enfaite » me font hurler de douleur, littéralement. Il faut avouer que c’est comme ça, et que je ne peux pas changer cette phobie, tout comme ma misophonie.

Pour citer une anecdote personnelle, il y a un bon paquet d’années de ça, j’avais eu un coup de foudre, un gros. Un jour, après en avoir marre de me poser des questions, je lui ai proposé un verre, qu’elle a décliné, mais le lendemain elle m’a envoyé un mail plus explicatif pour me faire comprendre que ce ne serait pas possible entre nous. Bon, ça arrive, un « non » ce n’est ni le premier ni le dernier, parce que c’est la vie et il faut l’accepter, et ça m’a permis de sortir de ma zone de confort (et de plus tard, entendre des « oui » de la part d’autres personnes). Mais ce qui m’a fait complètement changer d’avis sur cette personne était le contenu même de ce mail, écrit en langage SMS. La personne concernée n’avait plus 20 ans.

Langage SMS ? Mais NEXT, miss, sans regret !!!

Mais un mot me fait encore plus hurler, lors d’une conversation épistolaire.

LOL.

Parce qu’il n’y a rien derrière. On peut jeter un lol, par une phrase qui fait rire, mais parler d’un sujet sérieux, et lire en réponse un « lol » me laisse perplexe, lorsque un processus de « prise de connaissance en vue d’une relation » est entamée.

Lol, oui mais que veux-tu dire par là ? Que veux-tu exprimer ? (Parce que ce mot-là, aujourd’hui veut tout et rien dire, un peu comme un vieux livre qu’on cale sous un meuble, ça meuble une conversation, mais c’est plus de l’Ikea bon marché qu’un fauteuil Louis XIV).

Un exemple : je courtisais sur un site une demoiselle qui avait l’air d’être interessante, il y a quelques années. Nous avons échangé nos numéros, et un soir, alors que je lui partageais ma lecture du moment, j’ai eu une réponse qui là aussi, m’a faite vriller : « lolilollll mdrmdrmdr ».

Mon livre était : « Le pouvoir du moment présent » d’Eckart Tolle.
Donc rien de comique là-dedans.

Perplexe par la teneur de son propos, je lui demande plus d’explications, elle m’a juste répondu que pour elle « c’était pipo ». Okay, donc NEXT, pour le « trolol » et également, parce qu’elle ne partageait pas les mêmes valeurs en termes de spiritualité.

Un autre exemple … cette fois-ci j’étais en « relation sérieuse » avec une femme. Avec le temps, je me demandais vraiment ce que j’avais plus lui trouver, j’aimais discuter de choses intellectuelles, elle préférait les potins, parler des défauts et de la vie des autres, et lire « Closer ». Je n’ai rien contre ces gens-là, mais ce n’est pas mon truc ! Je pense que je l’idéalisais complètement. Je lui envoie un jour un SMS assez alarmant pour lui dire que je craignais qu’une de mes amies se soit enrôlée dans une secte. Là encore, rien de drôle, c’est plutôt grave (et heureusement mes craintes ne sont restées qu’au stade de peur, tout va bien pour elle). Et j’ai eu comme réponse « lol ».

J’imaginais la crédibilité de ses messages écrits, de l’image qu’elle pouvait renvoyer, de la mienne par la même occasion, puisque nous étions ensemble.

Quand j’écris, j’ai besoin de propos riches, j’ai besoin d’en savoir plus sur la personne que j’ai de l’autre côté de l’écran. Et le « lol » a le même effet que « cc sa va », un minimum d’éloquence, que diable, notre langue est riche (quoi que, pas autant que l’Allemand, mais c’est une autre histoire), et derrière se cachent des trésors (ne serait-ce que recevoir de belles lettres d’amour non copiées-collées d’un site … ) !

Et puis surtout : si tu dis LOL, le Bon Dieu il tue des petits chatons mignons. A moins que tu n’aimes pas les chats, un autre motif pour te nexter.