Guillaume Orsal

Régénérer les permaliens WordPress après une mise à jour

Guillaume Orsal — 2026-01-11T15:29:30Z

Après une mise à jour ou un déploiement WordPress, il peut arriver que les permaliens cessent de fonctionner. Une simple commande en ligne de commande permet de corriger le problème sans accéder au back-office.

Quand WordPress est mis à jour, certains sites se retrouvent avec des erreurs 404 ou des messages du type : Not Found – no results were found for the requested archive

Dans la majorité des cas, rien n'a disparu. C'est simplement le système des permaliens qui ne correspond plus à la configuration effective du serveur.

Pourquoi les permaliens doivent être régénérés ?

WordPress conserve sa structure d'URL dans sa base et part du principe que l'environnement ne change pas. Or il suffit d'un déplacement de dossier, d'une migration, d'un changement subtil sur Apache, pour que le système perde ses repères. Quand cela arrive, les requêtes ne sont plus réécrites correctement, ce qui se traduit par des pages introuvables alors que le contenu est bien là.

Solution sans interface : une commande shell

Quand on a accès à l'administration WordPress, le passage par Réglages > Permaliens suffit — mais si l'on travaille en SSH ou en déploiement automatisé, une commande résout le problème plus proprement :

 
 cd /chemin/vers/mon/site/wordpress \
 && php -r "define('WP_USE_THEMES', false); require('./wp-load.php'); flush_rewrite_rules();" \
 && echo "Permaliens régénérés avec succès"

Elle charge WordPress, force la régénération de la structure d'URL et s'arrête là, sans nécessiter d'accès au back-office.

Quand l'utiliser ?

Ce petit flush devient utile après un changement de domaine, une mise à jour majeure, l'ajout ou la suppression d'un plugin qui modifie les URLs, ou tout simplement après un déploiement CI/CD qui recopie le site sur un serveur neuf.

Si l'erreur se reproduit, il est possible de l'intégrer dans un script de maintenance ou un hook post-déploiement.

Bonnes pratiques et limites

La commande est efficace, mais ce n'est pas un bouton magique à actionner en continu. Régénérer les permaliens demande à WordPress de reconstruire sa mécanique interne. Cela reste une opération raisonnablement lourde en fonction du nombre de contenu sur le site.

Si après exécution les erreurs persistent, le problème est probablement ailleurs : mod_rewrite peut être désactivé, le .htaccess mal placé, ou le virtual host trop restrictif. Une vérification rapide de ces points résout la plupart des cas têtus.

Conclusion

En résumé, forcer WordPress à reconstruire ses permaliens règle en quelques secondes un problème qui peut faire perdre des heures si l'on cherche trop loin. C'est une astuce simple, propre, et idéale quand l'accès au tableau de bord n'est pas pratique ou quand on automatise ses déploiements.

llms.txt : un standard de documentation pour l'usage des contenus par les modèles d'IA

Guillaume Orsal — 2025-12-30T14:03:07Z

llms.txt est un standard émergent qui permet d'indiquer aux modèles d'IA comment les contenus d'un site web peuvent être utilisés. Cette page détaille le rôle du fichier llms.txt, son fonctionnement, ses principaux cas d'usage, ainsi que ses implications pour l'IA générative, le droit d'auteur et la notion de consentement des données.

Faut-il mettre en place un fichier llms.txt sur son site ? À quoi sert-il vraiment, et est-ce que les IA le respectent ? Tour d'horizon concret de ce standard émergent, entre bonnes pratiques, limites réelles et usages possibles.

TL ;DR

llms.txt est un fichier texte placé à la racine d'un site web (/llms.txt) permettant de documenter, de façon déclarative, les conditions d'utilisation de ses contenus par des modèles d'IA (LLMs). Ce standard émergent vise à améliorer la transparence entre créateurs de contenu et développeurs d'IA, sans mécanisme technique contraignant. Il permet notamment d'autoriser l'entraînement des modèles tout en en fixant les limites (usage commercial, attribution, données sensibles). Il s'inscrit dans la continuité des standards du web ouvert comme robots.txt ou Humans.txt.

Introduction : llms.txt, un standard émergent pour l'ère de l'IA générative

Avec la généralisation des modèles de langage de grande taille (Large Language Models, ou LLMs), une question devient centrale : comment les créateurs de contenu peuvent-ils indiquer aux systèmes d'IA les conditions d'utilisation de leurs données ?

Le fichier llms.txt est une proposition de standard visant à répondre à ce besoin. Il permet à un site web de documenter, de manière lisible par des agents automatisés, ses préférences concernant l'utilisation de ses contenus par des modèles d'IA.

L'objectif n'est pas d'imposer un mécanisme technique de contrôle, mais de fournir un cadre déclaratif, simple et décentralisé, que les développeurs d'IA peuvent choisir de respecter.

Contexte : pourquoi llms.txt a émergé

L'explosion des LLMs et des données d'entraînement

Depuis 2023, avec la démocratisation de modèles comme ChatGPT, les LLMs sont entraînés sur des volumes massifs de données issues du web public.

Concrètement, cela signifie que des contenus peuvent être réutilisés pour entraîner des modèles sans que leurs auteurs aient forcément été informés, ni même qu'ils aient eu l'occasion d'exprimer une position sur cet usage.

Ce flou pose un problème assez basique : il n'existe pas vraiment de moyen standard pour dire ce qui est acceptable ou non. Côté créateurs, difficile d'indiquer des conditions d'utilisation claires. Et côté développeurs, tout aussi difficile de savoir sur quelles bases ils peuvent s'appuyer pour utiliser ces contenus.

L'insuffisance des outils existants

robots.txt permet de réguler l'exploration des pages par des moteurs de recherche, mais ne s'applique pas explicitement aux usages liés à l'entraînement des modèles d'IA. Les balises offrent une granularité limitée et ne couvrent pas les cas d'usage spécifiques aux LLMs.

llms.txt propose une approche complémentaire : un fichier placé à la racine du site (/llms.txt), destiné à être consulté par des agents IA pour comprendre les règles d'usage déclarées par le propriétaire du contenu.

Qu'est-ce que llms.txt et comment l'utiliser

Le fichier llms.txt est un document texte simple, accessible publiquement, qui permet de documenter les politiques d'utilisation des contenus d'un site par des systèmes d'IA et des LLMs.

Il ne constitue ni une obligation légale, ni une barrière technique, mais un mécanisme de transparence destiné à faciliter le respect des préférences exprimées par les créateurs.

Ce que permet concrètement llms.txt

Contrairement à une idée assez répandue, llms.txt ne sert pas uniquement à interdire l'entraînement.

Son intérêt est justement de permettre des positions plus nuancées. On peut très bien autoriser l'entraînement des modèles, tout en encadrant les usages qui en sont faits ensuite. Par exemple, accepter un usage dans un cadre de recherche ou d'indexation, mais refuser une exploitation commerciale directe ou une intégration dans un modèle propriétaire.

De la même manière, il devient possible de poser des conditions d'attribution explicites, ou d'exclure certaines catégories de données, notamment lorsqu'elles sont personnelles ou sensibles.

Selon les cas, on peut aussi aller plus loin et définir des règles différentes en fonction des acteurs ou des types de modèles, même si ce point reste encore assez informel aujourd'hui.

Structure recommandée (exemple indicatif)

Le format suivant est une proposition illustrative, inspirée de mises en œuvre réelles. Il ne s'agit pas d'une spécification officielle et peut évoluer.

# llms.txt – AI usage policy (example)
 
 [Preferences]
 Allow-LLM-Training: true
 Allow-Document-Indexing: true
 Allow-LLM-Scraping: true
 Allow-Embedded-LLM-Training: false
 
 [Restrictions]
 Content-Restrictions: commercial-use-restriction, copyright-sensitive
 Sensitive-Data: excluded
 
 [Rules]
 GPT-4: allow-training, allow-indexing
 Claude: allow-training, allow-indexing
 OpenSource-Models: allow-training
 
 [Attribution-Requirements]
 Citation-Required: true
 Attribution-Format: Author, Date, URL
 
 [Contact]
 Email: contact@example.com
 
 [Last-Updated]
 Date: 2026-01-04
 Version: 1.1

Explication des principaux champs

Les principaux champs utilisés restent assez simples à comprendre, même sans spécification formelle :

Allow-LLM-Training : autorise l'utilisation du contenu pour l'entraînement des modèles d'IA
Allow-Embedded-LLM-Training : interdit l'intégration directe du contenu dans des modèles propriétaires fermés
Allow-Document-Indexing : autorise l'usage pour des systèmes de récupération de documents (RAG)
Sensitive-Data : exclut explicitement toute donnée personnelle ou sensible
Rules : permet de définir des règles spécifiques par acteur ou type de modèle
Citation-Required : rend l'attribution obligatoire pour tout usage

L'ensemble reste volontairement simple, l'objectif étant d'être lisible plutôt qu'exhaustif.

Pourquoi implémenter llms.txt

Pour les créateurs de contenu

Pour un créateur de contenu, l'intérêt de llms.txt est surtout de pouvoir reprendre la main sur quelque chose qui, jusqu'ici, restait implicite.

On peut autoriser l'entraînement sans pour autant accepter tous les usages derrière. Cela permet par exemple de poser des limites sur l'exploitation commerciale, de clarifier les conditions d'attribution, ou simplement d'exprimer une position sur la manière dont ses contenus peuvent être réutilisés.

Au-delà de l'aspect juridique, il y a aussi une logique de transparence. Formaliser ces règles, même de manière déclarative, revient à rendre explicite ce qui ne l'était pas.

Pour les développeurs d'IA

Côté développeurs, l'intérêt est différent mais complémentaire.

Disposer d'un fichier llms.txt permet d'identifier plus facilement les contenus qui peuvent être utilisés, et dans quelles conditions. Dans un contexte où les questions de droit d'auteur et de responsabilité sont de plus en plus présentes, ce type d'information devient utile pour cadrer les pratiques.

Cela ouvre aussi la voie à des processus plus traçables, où les sources et les conditions d'utilisation ne sont plus complètement implicites.

Bonnes pratiques

Dans la pratique, l'enjeu principal est d'éviter toute ambiguïté.

Un llms.txt efficace est d'abord un fichier explicite et cohérent. Il doit distinguer clairement les différents usages — entraînement, indexation, intégration — sans introduire de contradictions.

Lorsque le contenu est amené à être réutilisé, il est généralement pertinent de préciser les attentes en matière d'attribution. De la même manière, les données sensibles devraient être exclues sans ambiguïté.

Enfin, comme pour les autres fichiers de ce type, il est utile de maintenir le document à jour et de l'inscrire dans un ensemble plus large, aux côtés de robots.txt, Humans.txt ou security.txt.

Implémentation technique

Création du fichier

Créer un fichier texte nommé llms.txt à la racine du site (/llms.txt).

Vérification de l'accessibilité

curl -I https://www.example.com/llms.txt
 # Doit retourner : 200 OK

Lien optionnel depuis le site

Ou via un lien visible :

Politique d'utilisation IA (llms.txt)

Adoption et perspectives

llms.txt reste aujourd'hui un standard émergent, apparu autour de 2023–2024, et dont l'adoption est encore assez hétérogène.

Il n'existe pas, à ce stade, de reconnaissance formelle par un organisme de standardisation. Pour autant, la dynamique n'est pas nouvelle : on retrouve un schéma assez proche de celui de robots.txt à ses débuts, avec une adoption progressive portée par les usages, avant une éventuelle normalisation.

Dans le même temps, les évolutions réglementaires, notamment en Europe avec l'AI Act, pourraient renforcer l'intérêt de ce type de mécanisme déclaratif. Sans forcément le rendre obligatoire, elles contribuent à installer l'idée qu'une certaine transparence sur l'usage des données devient nécessaire.

Limitations et considérations

llms.txt présente aujourd'hui des limites qu'il vaut mieux avoir en tête dès le départ.

D'abord, son respect repose entièrement sur la bonne volonté des acteurs qui choisissent de le consulter. Il n'existe aucun mécanisme technique permettant de s'assurer qu'un agent s'y conforme réellement.

Ensuite, le fichier ne prévoit pas de système d'authentification. En pratique, il est donc impossible de distinguer de manière fiable les différents types d'agents ou de vérifier leur identité.

Enfin, la granularité reste assez limitée. Les règles s'appliquent globalement au site, sans possibilité fine de définir des politiques différentes selon les pages ou les sections.

Ces limites n'enlèvent pas tout intérêt au fichier, mais elles rappellent qu'il s'agit avant tout d'un outil de transparence, et non d'un dispositif de contrôle.

Conclusion : une ouverture encadrée plutôt qu'un refus global

llms.txt n'est pas un outil de blocage, mais un moyen d'exprimer clairement des conditions d'utilisation raisonnées.

Il permet d'autoriser l'entraînement des modèles d'IA tout en en fixant les limites : attribution, respect du droit d'auteur, exclusion des données sensibles et refus de certaines intégrations propriétaires.

À l'image de robots.txt ou Humans.txt, llms.txt s'inscrit dans la tradition du web ouvert : un écosystème fondé sur des conventions partagées, la transparence et la responsabilité.

Ressources et références

Site officiel llmstxt.org

Voir aussi

Humans.txt

Obfuscation d'email : CSS vs JavaScript, amélioration des performances SEO (LCP, CLS)

Guillaume Orsal — 2025-12-06T17:20:00Z

Lors d'une analyse de performance web, un JavaScript chargé uniquement pour l'obfuscation d'une adresse email a été identifié comme inutile. Cet article présente une alternative basée sur du CSS pur, puis une solution côté serveur permettant d'améliorer les performances SEO (LCP, CLS) tout en préservant l'expérience utilisateur, notamment sur mobile.

Pourquoi l'obfuscation d'email pose un problème de performance

L'obfuscation d'email, qui désigne les techniques utilisées pour rendre une adresse moins directement exploitable par des robots tout en restant lisible pour un humain, est une problématique ancienne du web. Historiquement, elle a souvent été traitée via du JavaScript chargé au runtime pour reconstruire une adresse ou un lien mailto:.

Même si ce type de script n'a pas toujours un impact mesurable immédiat sur les Core Web Vitals, il alourdit la page en ajoutant une ressource non essentielle. Il complexifie le rendu côté client, introduit des dépendances évitables et peut dégrader marginalement le LCP sur des pages simples. À cela s'ajoute un effet sur la lisibilité du code, ce qui nuit à long terme à la maintenabilité.

Dans une démarche d'optimisation SEO moderne, chaque ressource doit justifier sa présence.

Rappel : Core Web Vitals et performance perçue

Les Core Web Vitals sont un ensemble d'indicateurs définis par Google pour évaluer la qualité de l'expérience utilisateur réelle. Ils ne mesurent pas uniquement la rapidité brute, mais la perception du chargement et la stabilité de l'interface.

Le LCP (Largest Contentful Paint) reflète la vitesse d'affichage du contenu principal.

Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle de la page.

Un script JavaScript non essentiel peut retarder légèrement le rendu initial ou provoquer des recalculs inutiles.

Même lorsqu'un script n'entraîne pas de dégradation mesurable immédiate, sa suppression simplifie la chaîne de rendu et améliore la performance perçue, en particulier sur mobile. Ces principes s'inscrivent dans les recommandations de Google pour favoriser des pages rapides, stables et adaptées à l'indexation mobile-first.

Réduire le JavaScript pour améliorer le SEO technique

La performance web ne se résume pas à un score PageSpeed. Elle repose sur plusieurs principes clés : limiter le JavaScript non essentiel, réduire le travail du navigateur, stabiliser l'affichage pour éviter les décalages visuels (CLS) et améliorer la performance perçue, notamment sur mobile.

Supprimer un script inutile est souvent l'une des optimisations les plus simples et les plus efficaces.

Obfuscation d'email sans JavaScript : approche CSS

Il est possible d'afficher une adresse email sans qu'elle soit directement exploitable dans le code source, en utilisant uniquement du HTML et du CSS, sans JavaScript côté client.

La technique consiste à découper l'email dans des attributs data-*. Le CSS se charge ensuite de masquer le placeholder, et de reconstituer le contenu visible à partir des attributs. Ainsi, il n'y a plus de code côté client qui réalise le masquage de l'information.

Structure HTML

L'email est découpé en deux parties stockées dans des attributs data-*.

Il n'apparaît jamais directement sous forme exploitable dans le HTML.

L'application de la classe de style masque le contenu initial et reconstruit l'affichage via le CSS.

Le texte présent dans le reste dans le DOM mais n'est plus visible.

 data-email-user="guillaume"
 data-email-domain="orsal.net">
 [email protected]

Feuille de style CSS

/* Masque le contenu initial du bloc */
 .protected-email {
 font-size: 0;
 }
 
 /* Reconstruit visuellement l'email à partir des attributs data-* */
 .protected-email::before {
 font-size: 14px;
 content: attr(data-email-user) "@" attr(data-email-domain);
 }

Le choix de font-size: 0 masque le texte sans modifier la structure du DOM ni provoquer de recalcul de layout.

Bénéfices en termes de performance et de référencement

Cette solution présente plusieurs avantages du point de vue SEO et performance.

Il n'y a aucun JavaScript à charger ou exécuter, l'impact est donc nul sur le LCP et le CLS, le rendu est immédiat sans recalcul.

La compatibilité est maximale avec les navigateurs et la lecture reste possible par les moteurs de recherche.

Enfin, elle continue d'offrir une protection suffisante contre les collectes automatisées basiques des robots et s'inscrit dans une logique de sobriété et d'optimisation structurelle du front-end.

Limite fonctionnelle : l'expérience utilisateur sur mobile

Cette approche purement CSS présente toutefois une limite : l'adresse email affichée n'est pas cliquable.

Sur desktop, cela peut être acceptable. Sur mobile, l'utilisateur s'attend à ce qu'un email soit interactif et ouvre son client de messagerie.

Une optimisation technique ne doit pas se faire au détriment de l'expérience utilisateur.

Rétablir l'UX sans JavaScript : redirection côté serveur

Pour concilier performance, UX et protection minimale contre les bots, une solution consiste à utiliser une redirection côté serveur vers un lien mailto:.

L'email n'est jamais exposé sous forme de lien dans le HTML, et aucune logique JavaScript n'est ajoutée.

Script de redirection contact.php

 // Désactivation explicite du cache HTTP
 header('Cache-Control: no-cache, no-store, must-revalidate');
 header('Pragma: no-cache');
 header('Expires: 0');
 
 // Redirection vers le mailto
 header('Location: mailto:email@example.com?subject=contact');
 exit;
 ?>

Les en-têtes HTTP désactivant le cache sont essentiels. Une redirection mise en cache par un navigateur, un proxy ou un CDN pourrait conserver un comportement obsolète, ignorer une évolution future ou introduire des effets de bord difficiles à diagnostiquer.

Le script ne prend volontairement aucun paramètre utilisateur afin de limiter les risques d'abus, de détournement, ou d'envoi involontaire vers un point d'entrée exploitable.

Utilisation côté HTML

L'email masqué est ensuite encapsulé dans un lien pointant vers le script de redirection.


 
 [email protected]

Le lien est marqué en nofollow car l'objectif est uniquement l'action utilisateur, pas le référencement du script.

Conclusion

Cette approche supprime une dépendance JavaScript inutile, ce qui contribue à préserver des indicateurs tels que le LCP et le CLS. L'interactivité attendue sur mobile est également préservée, tout comme la limitation de l'exposition de l'adresse email. Le code obtenu est simple, maintenable et élégant.

L'optimisation des performances web et du référencement repose parfois sur des choix simples et structurants.

Réduire le JavaScript non essentiel en exploitant les capacités du CSS aura permis ici d'améliorer à la fois le SEO technique et la performance perçue, sans modifier l'expérience utilisateur.

Installer et utiliser Ollama : l'intelligence artificielle locale sous Linux

Guillaume Orsal — 2025-11-02T20:21:00Z

Diplômé d'un master en Intelligence Artificielle, je suis aujourd'hui développeur web fullstack spécialisé en Laravel, Livewire, React. J'intègre l'IA générative dans les projets web modernes pour créer des solutions intelligentes, sans dépendance aux API propriétaires.

Dans cet article, je vous guide pas à pas : installation d'Ollama sous Linux, choix et téléchargement de modèles open source comme Mistral ou Phi-3, tests de l'API REST et intégration dans Laravel pour bénéficier d'une IA locale rapide, économique et respectueuse de vos données.

Installation d'Ollama sous Linux

L'installation d'Ollama sous Linux (Debian/Ubuntu) est très simple grâce au script officiel fourni par l'équipe Ollama :

curl -fsSL https://ollama.com/install.sh | sh

Une fois installé, la commande ollama devient disponible et le service système démarre automatiquement. Par défaut, Ollama écoute uniquement en local sur 127.0.0.1:11434, ce qui garantit qu'aucune requête externe ne peut atteindre votre instance tant que vous ne modifiez pas la config réseau.

Pour vérifier le statut du service :

systemctl status ollama

Le service doit afficher active (running).

Vérifier l'écoute du service

Vérifier que le serveur Ollama écoute bien sur son port par défaut avec :

ss -tulpen | grep 11434

Vous devez obtenir une ligne similaire :

tcp LISTEN 0 4096 127.0.0.1:11434 ...

Cette configuration empêche toute exposition réseau accidentelle.

Si le port n'est pas visible, le service n'est probablement pas démarré ou le firewall local bloque l'accès.

Télécharger les modèles d'IA

Voici une sélection de modèles open-source adaptés à différents usages.

Ces modèles sont quantifiés (Q4/Q8), c'est-à-dire que leur précision numérique interne est réduite pour occuper moins de VRAM et calculer plus vite, tout en gardant une qualité de génération très proche du modèle d'origine.

Ollama n'embarque aucun modèle par défaut : vous devrez donc télécharger ceux dont vous avez besoin via {{ollama pull}}.

ollama pull mistral
 ollama pull phi3
 ollama pull neural-chat

Mistral : excellentes performances en génération de texte
Phi 3 : léger et performant
NeuralChat : ton conversationnel naturel

Pour lister les modèles installés :

ollama list

Premier test de génération

Vous pouvez interroger Ollama directement via son API REST locale. Par exemple, pour tester la génération avec Mistral :

curl http://127.0.0.1:11434/api/generate -d '{"model":"mistral","prompt":"Dis bonjour"}'

Ollama renvoie la réponse sous forme de tokens JSON en streaming, comme une API OpenAI.

Obtenir uniquement le texte final

jq est indispensable si vous souhaitez parser proprement les réponses JSON en ligne de commande ou dans vos scripts Bash.

L'outil s'installe avec la commande :

sudo apt-get install jq -y

Puis, un nouvel appel à l'API d'Ollama, chaîné à jq :

curl -sN http://127.0.0.1:11434/api/generate -d '{"model":"mistral","prompt":"Dis bonjour"}' | jq -rj --unbuffered 'select(.response) | .response';echo

Le texte s'affiche sans formatage JSON.

Une fonction Bash pour simplifier l'usage

Pour simplifier vos tests sans réécrire la commande curl, voici une fonction shell utilitaire à ajouter à vos alias dans .bash_aliases :

ollama-say() {
 if [ -z "$1" ]; then
 echo "Usage: ollama-say \"prompt\" [model]"
 return 1
 fi
 local PROMPT="$1"
 local MODEL="${2:-mistral}"
 curl -sN http://127.0.0.1:11434/api/generate \
 -d "{\"model\":\"$MODEL\",\"prompt\":\"$PROMPT\"}" \
 | jq -rj --unbuffered 'select(.response) | .response'
 echo
 }

Recharger les alias :

source ~/.bash_aliases

Vous pouvez maintenant appeler Ollama comme une mini-API locale directement depuis le terminal, en précisant dans la ligne de commande le prompt suivi du modèle :

ollama-say "Dis bonjour!" mistral

Après quelques secondes, vous obtiendrez la réponse sans formatage.

Accès distant via tunnel SSH

Ollama n'écoute par défaut que l'IP 127.0.0.1 pour des raisons de sécurité. Evitez absolument d'exposer le port 11434 directement sur Internet.

Si le service tourne sur une autre machine, par exemple un serveur disposant de meilleures capacités de calcul, vous pourrez créer un tunnel SSH.

Remplacez user par le login et serveur par l'IP ou le nom du serveur.

ssh -L 11434:localhost:11434 user@serveur

Le modèle devient alors accessible sur votre poste via http://localhost:11434. Le port local 11434 étant désormais redirigé vers le même port sur le serveur.

Pour lancer le tunnel SSH en arrière-plan :

ssh -N -f -L 11434:localhost:11434 user@serveur

Pour fermer le tunnel, il faudra s'attaquer directement au processus :

pkill -f "ssh -L 11434"

Cette approche permet un accès distant tout en conservant le niveau de sécurité d'un service local.

Intégration d'Ollama dans Laravel : cas d'usage concrets

L'API d'Ollama est compatible avec n'importe quel framework backend.

Ollama devient puissant lorsqu'il est intégré dans une architecture web moderne. Quelques applications concrètes :

Génération de contenu : Articles, descriptions produit, résumés
Analyse de texte : Catégorisation de commentaires, détection de spam
Suggestions intelligentes : Recommandations, auto-complétion
Recherche sémantique : Au-delà des mots-clés, recherche contextuelle via embeddings

Voici comment l'utiliser facilement dans Laravel via Http ::post() :

php
 $response = Http::post('http://localhost:11434/api/generate', [
 'model' => 'mistral',
 'prompt' => 'Génère une description produit concise pour : ' . $product->name,
 'stream' => false,
 ]);
 
 $description = $response->json()['response'];

Cela réduit drastiquement vos coûts API (OpenAI, Gemini) en gardant le contrôle total de vos données.

Performances et optimisation GPU

Bien que Ollama fonctionne sans GPU, les performances augmentent significativement avec une carte graphique supportée.

Sans GPU : 5-30 secondes par réponse selon le modèle
Avec GPU NVIDIA : Accélération de 5 à 20x, réponses en 1-5 secondes
VRAM nécessaire : Mistral ( 4GB), Phi 3 ( 2GB), Llama 2 ( 7GB)

Benchmark simple :

time ollama-say "Écris un email pour remercier un client"

En production avec une application Laravel, placer Ollama sur un serveur distinct, idéalement avec GPU, afin d'éviter de saturer votre serveur web.

Alternatives : Ollama vs llama.cpp vs LocalAI

Ollama : Installation simple, gestion facile des modèles, API REST standard. Meilleur pour débuter.

llama.cpp : Plus léger, excellente performance CPU. Idéal pour machines peu puissantes, mais installation plus complexe.

LocalAI : Interface web complète, compatible avec OpenAI API. Meilleur si vous migrez depuis OpenAI.

Pour un développeur fullstack Laravel cherchant du plug & play sans complexité, Ollama me semble le meilleur choix.

Erreurs courantes et dépannage

Ces erreurs sont les plus fréquentes lors d'un premier déploiement d'Ollama sur un serveur Linux.

Erreur « connection refused » : Ollama écoute uniquement sur localhost par défaut. Vérifier : `systemctl status ollama`. Pour l'accès distant, utiliser obligatoirement un tunnel SSH.

Modèle qui ne répond pas : Il calcule toujours. Attendre plus longtemps la première fois. Pour des timeouts, augmenter : `curl —max-time 300`.

VRAM saturée : Un modèle trop gros pour votre GPU. Vérifier : `nvidia-smi`. Réduire la taille du prompt ou utiliser un modèle plus léger.

Quantization confusion : Ollama gère automatiquement. Q4 = rapide mais moins précis, Q8 = plus lent mais meilleur. Aucune action requise sauf pour tirage manuel.

Conclusion

Ollama permet d'exécuter des modèles d'IA directement sur un serveur Linux, sans GPU obligatoire, sans dépendance tierce ni coûts récurrents.

L'installation est rapide, la configuration sûre, et la flexibilité excellente pour le développement, les tests et et la génération de contenu automatisée.

Une solution robuste et respectueuse des données, idéale pour développeurs et passionnés d'IA locale.

Ollama s'intègre parfaitement dans un workflow moderne Laravel/Livewire/React, que ce soit pour prototyper en local, automatiser des tâches éditoriales ou alimenter une plateforme SaaS interne.

Intégrer Ollama à votre stack full-stack : expertise et services

Intégrer Ollama dans une architecture web (Laravel, React, Livewire, Tailwind) demande une bonne compréhension du code métier, du traitement de texte génératif et des flux applicatifs.

Si vous envisagez d'ajouter de l'IA générative locale à votre application, je peux vous accompagner sur :

Intégration Laravel / API : prompts, streaming, validation, performances
Automatisation & file de jobs : tâches lourdes, exécution asynchrone
Choix et gestion des modèles : Mistral, Phi-3, formats d'entrée/sortie
Déploiement sur serveur Linux : installation, configuration et supervision de base

Je suis développeur web fullstack spécialisé Laravel et IA générative locale, avec une solide pratique Linux. Mon objectif : livrer des solutions fonctionnelles, maintenables et utilement assistées par l'IA.

Parlons de votre projet

Audit SEO : détecter les pages avec une balise noindex via script automatisé

Guillaume Orsal — 2024-12-08T14:05:07Z

En examinant la Google Search Console d'un site récemment, j'ai remarqué que certaines pages étaient non indexées à cause d'une balise noindex. Ces balises sont des balises meta . Comme je ne savais pas exactement quelles pages étaient concernées, j'ai décidé de créer un script simple pour parcourir le site et identifier toutes les pages contenant cette balise.

Dans cet article, je partage avec vous ce script et explique comment l'utiliser pour détecter les pages avec une balise noindex. Cela peut vous être utile si, comme moi, vous souhaitez corriger ce type de problème pour améliorer l'indexation de votre site par les moteurs de recherche.

Introduction : identifier les barrières d'indexation

La balise noindex est un élément clé de la gestion du SEO. Elle signale aux moteurs de recherche que certaines pages ne doivent pas être indexées, ce qui peut impacter significativement votre visibilité organique si utilisée à mauvais escient. Lors d'audits SEO, il est courant de découvrir des balises noindex involontaires ou mal configurées qui nuisent à l'indexation de pages stratégiques.

Cet article présente une approche automatisée pour parcourir un site et identifier toutes les pages contenant une balise noindex. Cette technique est indispensable pour diagnostiquer les problèmes d'indexation signalés dans la Google Search Console et évaluer si chaque balise noindex est justifiée.

Comprendre la balise noindex et ses impacts

La balise noindex est une directive du protocole robots placée dans la section d'une page HTML. Elle se présente sous la forme :

Ou de manière plus complète :

Impact sur l'indexation : Une page avec noindex est indexée temporairement par Google (pour vérifier la balise), puis supprimée des résultats de recherche après quelques semaines. Ce processus peut causer des fluctuations dans votre classement et votre couverture indexée.

Quand noindex est justifiée :
Pages de test ou développement
Contenus en double (variantes de filtre, paramètres d'URL)
Pages archivées ou dépréciées intentionnellement
Pages avec contenu sensible non destiné au public

Quand noindex pose problème :
Appliquée accidentellement à des pages stratégiques
Pré-configurée sur un thème ou un CMS
Résultant de migrations mal gérées
Présente dans une feuille de style CSS appliquée globalement

Diagnostic : automatiser la détection noindex

Plutôt que d'inspecter manuellement chaque page, un script d'audit permet un diagnostic rapide et complet. Voici un script shell Linux qui télécharge votre site et identifie toutes les pages avec noindex.

Script de détection noindex complet

#!/bin/bash
 
 # ============================================
 # Script d'audit SEO : détection des balises noindex
 # Utilisation : ./script.sh https://www.exemple.com [PROFONDEUR]
 # ============================================
 
 # Vérifier si une URL a été fournie
 if [ -z "$1" ]; then
 echo "Usage: $0  [PROFONDEUR]"
 echo "Exemple : $0 https://www.exemple.com 3"
 exit 1
 fi
 
 SITE_URL="$1"
 DEPTH=${2:-2} # Profondeur par défaut : 2
 OUTPUT_DIR="site_scan_$(date +%s)"
 NOINDEX_FILE="noindex_pages_$(date +%Y%m%d_%H%M%S).txt"
 
 # Créer un répertoire temporaire pour stocker les pages
 mkdir -p "$OUTPUT_DIR"
 echo "[*] Création du répertoire : $OUTPUT_DIR"
 echo "[*] Profondeur de parcours : $DEPTH"
 
 # Télécharger le site avec wget
 # --mirror : mode miroir (télécharge récursivement)
 # --convert-links : convertit les liens pour navigation locale
 # --adjust-extension : ajoute .html si nécessaire
 # --page-requisites : télécharge les ressources (CSS, JS, images)
 # --no-parent : n'explore pas les répertoires parents
 # --level : limite la profondeur de récursion
 echo "[*] Téléchargement du site en cours..."
 wget --mirror \
 --convert-links \
 --adjust-extension \
 --page-requisites \
 --no-parent \
 --level="$DEPTH" \
 "$SITE_URL" \
 -P "$OUTPUT_DIR" \
 --quiet
 
 # Rechercher les pages contenant la balise noindex
 echo "[*] Analyse des pages pour détecter noindex..."
 find "$OUTPUT_DIR" -type f -name "*.html" | while read -r file; do
 # Regex expliquée :
 # ]* : ouverture de la balise meta (accepte tous les attributs)
 # name="robots" : recherche l'attribut name avec la valeur robots
 # [^>]* : accepte d'autres attributs (ex: http-equiv)
 # content="[^"]*noindex : vérifie que noindex est dans l'attribut content
 
 if grep -qi ']*name="robots"[^>]*content="[^"]*noindex' "$file"; then
 echo "Page avec noindex trouvée : $file"
 echo "$file" >> "$NOINDEX_FILE"
 fi
 done
 
 # Afficher les résultats
 echo ""
 echo "[*] Résultats :"
 if [ -f "$NOINDEX_FILE" ]; then
 count=$(wc -l < "$NOINDEX_FILE")
 echo "⚠️ $count page(s) contenant une balise noindex détectée(s)"
 echo "📄 Fichier de résultats : $NOINDEX_FILE"
 echo ""
 echo "=== PAGES AVEC NOINDEX ==="
 cat "$NOINDEX_FILE"
 else
 echo "✓ Aucune balise noindex n'a été trouvée."
 fi

Utilisation du script

1. Rendre le script exécutable

chmod +x script_noindex.sh

2. Lancer l'audit

Avec une profondeur par défaut (2 niveaux) :

./script_noindex.sh https://www.exemple.com

Avec une profondeur personnalisée (ex : 4 niveaux pour un gros site) :

./script_noindex.sh https://www.exemple.com 4

3. Consulter les résultats

Le script génère un fichier noindex_pages_YYYYMMDD_HHMMSS.txt contenant la liste des pages affectées. Ouvrez ce fichier pour identifier les problèmes.

Interprétation des résultats et diagnostic

Cas 1 : Pages intentionnellement en noindex Si vous trouvez des pages avec noindex que vous aviez volontairement marquées, c'est normal. Vérifiez simplement que chacune de ces pages mérite réellement cette balise.

Cas 2 : Pages stratégiques affectées Si le script détecte noindex sur des pages que vous souhaitez indexer :
Vérifiez la source du problème : CMS, thème, configuration serveur, ou erreur humaine
Supprimez ou modifiez la balise en noindex, nofollow vers index, follow ou supprimez-la complètement
Forcez une exploration Google en soumettant l'URL via la Search Console

Cas 3 : Aucune balise noindex détectée Excellent ! Mais assurez-vous que le site était complet. Vérifiez la profondeur utilisée et augmentez-la si certaines sections ne sont pas explorées.

Limitations et considérations importantes

Respect de robots.txt : Le script wget respecte le fichier robots.txt de votre site. Si des pages sont bloquées par robots.txt, elles ne seront pas téléchargées. Modifiez la commande wget avec —execute robots=off si vous voulez ignorer robots.txt (à utiliser avec prudence).

Sites très volumineux : Pour les sites avec des milliers de pages, augmenter la profondeur peut être très long. Envisagez de limiter le domaine ou d'utiliser des crawleurs SEO professionnels comme Screaming Frog pour les audits complets.

Pages dynamiques : Ce script capture le HTML statique. Les pages générées en JavaScript côté client ne seront pas correctement analysées. Pour les sites single-page application (SPA), utilisez des outils comme Puppeteer ou Playwright.

Authentification requise : Si votre site demande une authentification, le script ne peut pas y accéder. Vous devrez ajuster wget pour fournir des identifiants ou tester manuellement.

Bonnes pratiques pour la gestion de noindex

1. Documentez vos décisions : Maintenez un registre des pages intentionnellement en noindex et des raisons sous-jacentes 2. Auditez régulièrement : Relancez ce script trimestriellement pour détecter toute dégradation 3. Validez en Search Console : Utilisez l'onglet « Couverture » pour croiser les résultats et identifier les pages non indexées pour d'autres raisons 4. Privilégiez disallow dans robots.txt : Pour les pages vraiment privées, robots.txt est plus approprié que noindex 5. Testez avant déploiement : Utilisez une branche de staging pour valider vos changements avant production

Conclusion

La détection automatisée des balises noindex est une étape critique d'un audit SEO complet. Ce script vous permet d'identifier rapidement les problèmes d'indexation et de prendre les mesures correctives nécessaires. En combinant cet outil avec la Search Console et une bonne compréhension des impacts, vous pouvez optimiser considérablement votre couverture indexée et votre visibilité organique.

L'important est de maintenir un équilibre : bloquer intentionnellement ce qui doit l'être, tout en assurant que vos pages stratégiques restent pleinement accessibles aux moteurs de recherche.

Automatisation de la reconnexion du clavier après la veille sous Linux

Guillaume Orsal — 2024-06-23T13:27:00Z

Sur mon laptop, sous Ubuntu, parfois après la sortie de veille je rencontre des problèmes avec mon clavier qui ne répond plus. Impossible de le débrancher / rebrancher évidemment et je suis obligé de passer par un clavier externe pour le relancer. Voici la solution d'automatisation mise en place pour la reconnexion.

Une analyse longue et minutieuse des logs système m'a permis d'identifier le message d'erreur suivant lorsque mon clavier cessait de fonctionner :

Failed to enable keyboard on isa0060/serio0

Si je ne veux plus me retrouver bloqué au réveil de l'appareil, il va falloir mettre en place un script qui va détecter et corriger l'erreur automatiquement.

Créer un script de surveillance et de reconnexion

La première étape consiste à créer un script qui vérifiera les erreurs de clavier dans les logs du noyau (dmesg) et reconnectera le clavier si nécessaire.

Pour éviter de relancer le clavier indéfiniment, il faut vérifier que la déconnexion est intervenue après la dernière relance du clavier, d'où le stockage de la date de dernière relance dans /var/log/last_keyboard_reconnect.

Créer le script avec la commande :

sudo vi /usr/local/bin/check_keyboard.sh

Puis y insérer le code suivant :

#!/bin/bash
 
 # Chemin du fichier de log
 LOGFILE="/var/log/keyboard_monitor.log"
 
 # Fichier pour stocker l'heure de la dernière reconnexion
 LAST_RECONNECT_FILE="/var/log/last_keyboard_reconnect"
 
 # Initialisation de la date de dernière reconnexion
 last_reconnect=0
 
 # Test s'il y a déjà eu des déconnexions du clavier dans la session courante
 if sudo dmesg | grep -q "atkbd serio0: Failed to enable keyboard on isa0060/serio0";
 then
 # Oui, alors on récupère la date de dernière connexion depuis le fichier
 if [ -f $LAST_RECONNECT_FILE ]; then
 last_reconnect=$(cat $LAST_RECONNECT_FILE)
 fi
 else
 # Non, alors on initialise le fichier contenant la date de dernière reconnexion
 echo 0 > $LAST_RECONNECT_FILE
 fi
 
 # Vérifier les erreurs de clavier dans dmesg depuis la dernière reconnexion
 if sudo dmesg | awk -v ref="$last_reconnect" '{
 # Extraire le timestamp en enlevant les crochets
 match($0, /^\[([0-9]+\.[0-9]+)\]/, arr)
 timestamp = arr[1]
 
 # Comparer le timestamp avec la référence
 if (timestamp > ref) {
 print $0
 }
 }' | grep -q "atkbd serio0: Failed to enable keyboard on isa0060/serio0" ; then
 
 # Reconnexion du clavier
 sudo sh -c 'echo -n "reconnect" > /sys/bus/serio/devices/serio0/drvctl'
 
 # Mise à jour de la date de dernière reconnexion
 last_error_time=$(sudo dmesg | grep "atkbd serio0: Failed to enable keyboard on isa0060/serio0" | tail -1 | awk '{print substr($1, 2, length($1) - 2)}')
 echo $last_error_time > $LAST_RECONNECT_FILE
 
 # Log
 echo "$(date +%Y%m%d-%T);$last_error_time;Clavier reconnecté" >> $LOGFILE
 else
 echo "$(date +%Y%m%d-%T);$last_reconnect;Pas de problème détecté" >> $LOGFILE
 fi

La reconnexion logiciel du clavier s'effectue dans le script par la commande :

sudo sh -c 'echo -n "reconnect" > /sys/bus/serio/devices/serio0/drvctl'

N'oubliez pas de rendre le script exécutable :

sudo chmod +x /usr/local/bin/check_keyboard.sh

Créer un hook systemd-sleep pour la sortie de veille

Pour moi le problème se présente en sortie de veille de l'ordinateur. Je vais donc utiliser le hook de systemd adapté : systemd-sleep

Pour cela, je vais placer un script dans le répertoire /lib/systemd/system-sleep/. Assurez-vous qu'il existe et sinon vous pouvez le créer par la commande :

sudo mkdir -p /lib/systemd/system-sleep/

L'ensemble des scripts dans ce répertoire sont exécutés à chaque mise en veille et sorte de veille. Je vais donc y créer un script :

sudo vi /lib/systemd/system-sleep/keyboard_resume.sh

Lors de l'appel de ce script, il reçoit plusieurs paramètre. Le premier paramètre $1 contient soit la valeur pre indiquant la mise en veille, soit la valeur post indiquant la sortie de la veille. Voici donc le script pour jouer le script de relancer du clavier au réveil de l'ordinateur :

#!/bin/bash
 
 case $1 in
 post)
 /usr/local/bin/check_keyboard.sh
 ;;
 esac

Ne pas oublier de rendre le script exécutable.

sudo chmod +x /lib/systemd/system-sleep/keyboard_resume.sh

L'analyse du fichier de log /var/log/keyboard_monitor.log après un réveil de l'ordinateur permettra de vérifier que le script s'est bien exécuté, et au besoin a reconnecté le clavier.

Gestion des disques sous Linux – mémo de commandes shell (Ubuntu & Debian)

Guillaume Orsal — 2022-12-27T20:32:00Z

Une compilation de commandes shell Linux que j'utilise régulièrement pour la gestion de disques et partitions (Ubuntu/Debian).

Elle ne se veut ni exhaustive, ni pédagogique, mais sert de mémo technique basé sur mon expérience de terrain en développement et administration de systèmes Linux.

Cette pratique s'inscrit dans un usage quotidien de Linux depuis Debian Slink, pour le développement et la mise en production de projets web Laravel et de travaux en intelligence artificielle.

Elles sont regroupées par thématique :

Identifier disques et partitions disponibles sur l'ordinateur

Réparer un disque défectueux

Automatiser les contrôles

Fdisk pour disques GPT

Formatage d'un disque vierge

Partitions chiffrées avec LUKS

Réparer une clé usb FAT32 en lecture seule sous Linux

Voir l'espace disque utilisé

Vérifier l'état SMART d'un disque

Monter / démonter une partition

Diagnostics bas niveau

Inspection ext* sans montage

FAT32 récalcitrant

Quand la table de partitions ne veut rien savoir

Récupération de données

Forensic

Analyse du header GPT

Carving manuel

Analyse du journal ext4 avec debugfs

Récupération d'inodes supprimés

Analyse des performances disque

Recherche de malware au niveau boot (MBR / GPT)

Réinitialisation du code d'amorçage (MBR)

Monter un système de fichiers distant via SSH

Gérer le chariot du lecteur DVD

Identifier disques et partitions disponibles sur l'ordinateur

Avant toute opération sur un disque ou une partition, il est utile de connaître leur disposition exacte et leurs caractéristiques.

Liste des disque physiques :

sudo lshw -class disk

Informations détaillées sur les partitions :

sudo fdisk -l

Liste des partitions, types et points de montage :

sudo blkid -o list -c /dev/null

ou, plus lisible dans la plupart des cas :

lsblk -o NAME,SIZE,FSTYPE,TYPE,PTTYPE,LABEL,PARTLABEL,MOUNTPOINT,UUID

Ces commandes permettent d'identifier précisément :

les disques physiques
les partitions
leur type de système de fichiers
leur point de montage
leur UUID

Ces informations sont nécessaires pour cibler correctement un disque ou une partition dans les opérations suivantes.

Dans la suite, j'utiliserai les notations suivantes :

/dev/sdX pour un disque
/dev/sdXN pour une partition

où X est la lettre du disque et N le numéro de partition.

Exemple : /dev/sda1

Réparer un disque défectueux

Il existe de nombreuses approches face à un disque défectueux. Voici celles que j'utilise ponctuellement.

Trouver des secteurs défectueux sur un disque.

⚠️ Cette opération est très longue : la commande parcourt l'ensemble des secteurs du disque et écrit la liste des secteurs défectueux dans un fichier badsectors.txt.

sudo badblocks -v /dev/sdXN > badsectors.txt

Marquer les secteurs erronés d'un disque afin qu'ils ne soient plus utilisés

Les secteurs défectueux sont alors exclus, ce qui limite les risques de corruption ou de perte de données.

NB : la partition doit être démontée au préalable via la commande :sudo umount /dev/sdXN

Le fichier badsectors.txt est le fichier généré par la commande badblocks.

sudo e2fsck -l badsectors.txt /dev/sdXN

fsck est l'utilitaire de vérification des systèmes de fichiers sous Linux. e2fsck en est la version dédiée aux systèmes de fichiers de type ext2/ext3/ext4.

Récupérer les informations du dernier contrôle fsck

sudo tune2fs -l /dev/sdXN

Pour extraire uniquement les informations liées à la fréquence d'analyse des disques et à l'historique des contrôles :

sudo tune2fs -l /dev/sdXN | grep -E "Last\ c|Max|Mount"

Automatiser les contrôles

fsck peut être lancé manuellement, mais il est également possible de planifier des contrôles automatiques après un certain nombre de redémarrages.

La commande suivante force un contrôle fsck de la partition /dev/sdXN tous les 10 redémarrages :

sudo tune2fs -c 10 /dev/sdXN

Une valeur de -1 désactive fsck et ses contrôles automatiques.
Une valeur de 1 force un contrôle à chaque démarrage.

Si la partition est montée via le fichier /etc/fstab, il convient également de vérifier la ligne correspondante à la partition. Un dernier champ positionné à 0 désactive le contrôle au démarrage.

Fdisk pour disques GPT

Les disques modernes utilisent souvent une table de partitions GPT, incompatible avec fdisk : on utilise alors gdisk pour manipuler correctement les partitions.

Installation de l'outil :

sudo apt-get update
 sudo apt-get install gdisk

Formatage d'un disque vierge

Création de la partition :

— Lancer l'outil de gestion des partitions :

sudo parted /dev/sdX

Dans parted, exécuter les commandes suivantes.

— Création de la table de partition GPT :

mklabel gpt

— Création d'une partition primaire ext4 occupant l'ensemble du disque :

mkpart primary ext4 2048s 100%

— Vérifier la table de partitions :

print

— Quitter parted :

quit

Création du système de fichier ext4 :

sudo mkfs.ext4 /dev/sdXN

Attribution d'un label à la partition :

sudo e2label /dev/sdXN

Partitions chiffrées avec LUKS

Lorsqu'un disque ou une partition est chiffré (par exemple pour des données sensibles), il n'apparaît pas comme un FS classique et nécessite une étape d'identification distincte.

Certaines partitions peuvent être chiffrées avec LUKS afin de protéger les données.

Voici comment identifier les volumes chiffrés actuellement présents sur le système :

sudo dmsetup ls --target crypt

Réparer une clé usb FAT32 en lecture seule sous linux

Une clé USB montée en lecture seule empêche toute modification ou suppression de fichiers. Ce comportement est fréquent sur des supports FAT32 présentant des erreurs.

Ce cas se rencontre souvent lorsque le système de fichiers FAT32 devient incohérent après une suppression ou un retrait non propre de la clé USB.

Vérifier le type de système de fichiers et identifier la partition

Lister les périphériques FAT32 afin d'identifier la partition concernée :

lsblk -f |grep FAT32

Ou, si l'identifiant est déjà connu :

lsblk -f /dev/sdXN

Démonter la clé USB

La partition doit être démontée avant toute tentative de réparation :

sudo umount /dev/sdXN

Lancer la réparation du système de fichiers FAT32

sudo dosfsck -w -r -l -a -v -t /dev/sdXN

avec les paramètres suivants :

-w : écrit les corrections sur le disque
-r : interaction lors de la réparation
-l : liste les fichiers présentant des erreurs
-a : corrige automatiquement les erreurs
-v : mode verbeux
-t : marque les clusters défectueux dans la FAT

Une fois la réparation terminée, débrancher puis rebrancher physiquement la clé USB.

Voir l'espace disque utilisé

Espace utilisé / disponible par système de fichiers :

df -h

Espace occupé par répertoire (taille) :

du -sh /chemin

Afficher les points de montage :

findmnt

Vérifier l'état SMART d'un disque

La plupart des disques supportent SMART : on peut obtenir les données d'état :

sudo smartctl -a /dev/sdX

(Il faut installer : smartmontools)

Monter / démonter une partition

Monter une partition :

sudo mount /dev/sdXN /point/de/montage

Démonter :

sudo umount /dev/sdXN

Diagnostics bas niveau (quand ça commence à sentir mauvais)

Lire l'ensemble d'un disque sans le monter (détection de lenteurs ou d'erreurs E/S) :

sudo dd if=/dev/sdX of=/dev/null bs=1M status=progress

Rechercher les erreurs disque côté noyau :

dmesg | grep -i -E "error|fail|ata|i/o"

Inspection ext* sans montage

Afficher les métadonnées complètes d'un système de fichiers ext* :

sudo dumpe2fs /dev/sdXN | less

Lister les superblocks disponibles :

sudo dumpe2fs /dev/sdXN | grep -i superblock

Réparer un système de fichiers à partir d'un superblock alternatif :

sudo e2fsck -b 32768 /dev/sdXN

Les systèmes de fichiers ext* disposent de superblocks alternatifs utilisables en cas de corruption.

FAT32 récalcitrant (cas désespérés)

Réparation automatique non interactive :

sudo dosfsck -a -w -v /dev/sdXN

Réécriture du boot sector FAT :

sudo dosfsck -b /dev/sdXN

Quand la table de partitions ne veut rien savoir

Forcer la relecture de la table de partitions :

sudo partprobe /dev/sdX

sudo blockdev --rereadpt /dev/sdX

Récupération de données (old school)

Attention la commande dd ne vérifie rien et n'avertit pas. Une erreur de périphérique (if= / of=) entraîne une perte de données immédiate et irréversible.

Copier un disque en ignorant les erreurs :

sudo dd if=/dev/sdX of=/dev/sdY conv=noerror,sync status=progress

Variante plus robuste avec journal de récupération :

sudo ddrescue /dev/sdX /dev/sdY rescue.log

Forensic

Cloner un disque vers une image brute :

sudo dd if=/dev/sdX of=image.raw bs=4M status=progress

Examiner une image disque sans la monter :

sudo file image.raw

Associer une image disque à un périphérique loop :

sudo losetup -fP image.raw

Note : un périphérique loop permet de traiter un fichier image comme un périphérique bloc.

Lister les périphériques loop actifs :

losetup -a

Examiner les partitions détectées dans l'image :

lsblk /dev/loopX

Lire un secteur précis (ex. MBR / GPT header) :

sudo dd if=/dev/sdX bs=512 count=1 | hexdump -C

Lire un secteur à un offset donné :

sudo dd if=/dev/sdX bs=512 skip=2048 count=1 | hexdump -C

Monter une partition d'image disque via offset :

sudo mount -o loop,ro,offset=1048576 image.raw /mnt/forensic

(offset = début de partition en octets)

Monter en lecture seule (forensic safe) :

sudo mount -o ro,noload /dev/loopXpY /mnt/forensic

Identifier le type de données présentes :

file image.raw

Extraire les chaînes lisibles (recherche d'artefacts) :

strings image.raw | less

Recherche ciblée (ex. mots-clés) :

strings image.raw | grep -i "password"

Analyse et récupération de tables de partitions :

sudo testdisk image.raw

Extraction de fichiers sans table de partitions :

sudo photorec image.raw

Analyse du header GPT (primaire / secondaire)

Cette analyse est utile lorsque la table de partitions GPT est corrompue ou incohérente, mais que le disque contient encore des données exploitables. L'objectif est de vérifier l'état du header GPT principal et de son backup, et de déterminer lequel peut servir de référence pour une restauration.

Lire le header GPT primaire (LBA 1) :

sudo dd if=/dev/sdX bs=512 skip=1 count=1 | hexdump -C

Lire le header GPT secondaire (dernier secteur du disque) :

sudo dd if=/dev/sdX bs=512 skip=$(($(blockdev --getsz /dev/sdX)-1)) count=1 | hexdump -C

Sauvegarder et comparer les deux headers :

sudo dd if=/dev/sdX bs=512 skip=1 count=1 of=gpt_primary.bin
 sudo dd if=/dev/sdX bs=512 skip=$(($(blockdev --getsz /dev/sdX)-1)) count=1 of=gpt_backup.bin
 cmp gpt_primary.bin gpt_backup.bin

Inspecter les informations GPT lisibles :

sudo sgdisk -i 1 /dev/sdX

Vérifier la cohérence globale de la table GPT :

sudo sgdisk -v /dev/sdX

Carving manuel (extraction sans table de partitions ni système de fichiers)

Le carving manuel intervient lorsque la table de partitions et le système de fichiers sont irrécupérables. L'objectif est d'extraire directement des fichiers ou des données brutes à partir de signatures connues, sans s'appuyer sur aucune métadonnée.

Identifier le type général de données présentes dans une image disque :

file image.raw

Rechercher des signatures de fichiers connues :

grep -a -b "JFIF" image.raw
 grep -a -b "%PDF" image.raw

Extraire un fichier à partir d'un offset connu :

dd if=image.raw of=fichier.bin bs=1 skip=OFFSET count=TAILLE

Examiner le contenu extrait :

file fichier.bin
 hexdump -C fichier.bin | less

Analyse du journal ext4 avec debugfs

Cette analyse est utile lorsque des fichiers ont disparu récemment ou après un crash, mais que le système de fichiers ext4 est encore montable ou partiellement cohérent. L'objectif est d'examiner les structures internes (journal, inodes, blocs) afin d'identifier des données encore récupérables.

Ouvrir une partition ext4 avec debugfs (sans montage) :

sudo debugfs /dev/sdXN

puis dans debugfs les commandes d'analyse ci-dessous.

Afficher les informations générales du système de fichiers :

stats

Examiner l'état du journal :

logdump

Lister les inodes récemment modifiés (selon le journal) :

lsdel

(Quitter debugfs avec quit)

Récupération d'inodes supprimés (ext4)

Cette méthode s'applique lorsque des fichiers ont été supprimés mais que leurs blocs n'ont pas encore été réutilisés. L'objectif est de restaurer directement les données à partir des inodes supprimés, sans passer par le nom de fichier original.

Un inode est la structure centrale d'un système de fichiers Linux (ext2/ext3/ext4). Il ne contient pas le nom du fichier, mais l'ensemble de ses métadonnées et les pointeurs vers les données.

Un inode contient notamment :

le type (fichier, répertoire, lien, etc.)
les permissions
l'UID et le GID
la taille
les horodatages (atime, mtime, ctime, crtime selon le système de fichiers)
les pointeurs vers les blocs de données :
— directs
— indirects
— double et triple indirects

Le nom du fichier n'est pas stocké dans l'inode, mais dans le répertoire. Un répertoire est une simple table associant un nom à un numéro d'inode : nom → inode

Conséquence :

supprimer un fichier supprime le lien nom → inode
l'inode peut encore exister
les blocs de données peuvent rester intacts

Lister les inodes supprimés :

sudo debugfs /dev/sdXN
 lsdel

Examiner un inode supprimé :

stat

Extraire le contenu d'un inode vers un fichier :

dump fichier_recupere.bin

Analyser le fichier extrait :

file fichier_recupere.bin

Analyse des performances disque (diagnostic bas niveau)

Cette analyse est utile pour identifier des lenteurs anormales, des timeouts E/S ou des comportements dégradés liés au matériel. L'objectif est de distinguer un problème logiciel d'un problème physique ou firmware.

Mesurer les performances brutes en lecture séquentielle :

sudo hdparm -tT /dev/sdX

Tester la latence de lecture sans cache :

sudo dd if=/dev/sdX of=/dev/null bs=4K count=100000 iflag=direct status=progress

Surveiller les erreurs E/S et timeouts :

dmesg | grep -i -E "i/o error|timeout|ata"

Recherche de malware au niveau boot (MBR / GPT)

Cette vérification est pertinente en cas de comportement anormal persistant, y compris après réinstallation du système. L'objectif est d'identifier une modification du code d'amorçage (bootsector, MBR ou GPT).

Lire le secteur d'amorçage MBR (512 octets) :

sudo dd if=/dev/sdX bs=512 count=1 | hexdump -C

Lire le header GPT primaire :

sudo dd if=/dev/sdX bs=512 skip=1 count=1 | hexdump -C

Comparer avec un disque sain ou une sauvegarde :

cmp mbr_suspect.bin mbr_sain.bin

Rechercher des chaînes suspectes :

strings mbr_suspect.bin

Réinitialisation du code d'amorçage (MBR)

Le MBR (Master Boot Record) correspond aux 512 premiers octets d'un disque en schéma de partition de type MBR.

Il contient le code d'amorçage primaire ainsi que la table de partitions. Une corruption ou une modification malveillante de ce code peut empêcher le démarrage du système ou persister malgré une réinstallation.

Cette opération consiste à neutraliser le code d'amorçage existant afin de repartir sur une base saine.

Écraser le code MBR (sans toucher aux partitions) :

sudo dd if=/dev/zero of=/dev/sdX bs=440 count=1

Supprimer complètement la table GPT et les métadonnées associées :

sudo sgdisk --zap-all /dev/sdX

Réinstaller un chargeur d'amorçage légitime :

grub-install /dev/sdX

En cas de doute de compromission du boot secteur, l'idée est de supprimer le secteur d'amorçage douteux (MBR ou GPT selon le type), puis d'en réinstaller un propre avec grub.

Monter un système de fichiers distant via SSH (SSHFS)

Le montage via SSHFS permet d'accéder à un système de fichiers distant comme s'il était local, en s'appuyant uniquement sur une connexion SSH. C'est particulièrement utile pour l'analyse, la récupération de données ou l'accès ponctuel à des fichiers distants sans exposer de services supplémentaires.

Installer sshfs :

sudo apt-get install sshfs

Monter un répertoire distant :

sshfs user@serveur:/chemin/distant /mnt/ssh

Démonter proprement :

fusermount -u /mnt/ssh

Gérer le chariot du lecteur DVD

Ejecter le disque :

eject

Rentrer le chariot du disque, si le lecteur le permet :

eject -t

SERP, SPIP, breadcrumb et SEO

Guillaume Orsal — 2018-04-24T12:48:43Z

Vous avez peut-être déjà remarqué que les SERP de Google ont souvent un affichage différent. Les SERP, pour Search Engine Result Page, ce sont les pages résultats d'un moteur de recherche.

La variation qui m'intéresse ici est la ligne qui contient traditionnellement l'url de la page, la petite ligne verte. Parfois, elle se présente sous la forme d'un fil d'ariane, qui reprend le fil d'ariane présent sur la page. Je trouve cela plus parlant pour la personne qui fait une recherche, alors voyons comment mettre ça en place. [sommaire]

Web sémantique & schema.org

Bon, aujourd'hui il y a des projets de voiture autonome sans pilote plutôt bien avancés. Mais voilà, un moteur de recherche n'arrive pas encore à détecter et lire tout seul le fil d'ariane et il va falloir l'aider. Pour cela on va utiliser le Web sémantique. Nous allons ajouter des balises dans les pages Web qui vont donner du sens au contenu en ajoutant des meta informations qui permettent aux moteurs de recherche de mieux comprendre le contenu des pages Web.

Il existe plusieurs systèmes de balises comme microformats ou Dublin core, mais je vais utiliser schema.org car il me semble être mieux reconnu par Google. D'ailleurs c'est celui qu'ils utilisent dans leurs exemples.

Ces différents systèmes ne sont pas incompatibles entre eux, bien au contraire, je vous invite à tous les utiliser sur vos pages Web pour améliorer votre référencement. Ils permettent de représenter de manière structurée plein de types d'information. Cela dépasse le cadre de cet article, et nous allons nous focaliser sur les BreadcrumbList. « Breadcrumb trail » c'est le terme anglais pour désigner le fil d'Ariane sur les pages Web.

Prenons un exemple

Voici un exemple de fil d'ariane :

Accueil > SEO > Web sémantique > SERP, SPIP et breadcrumb

Schema.org définit donc une structure pour les breadcrumb, c'est à dire une liste et une hiérarchie d'information qui permet de définir un fil d'Ariane et ses éléments. Pour faire simple, je vais me limiter ici aux champs obligatoires ou les plus pertinents : le nom, l'url et la position. En explorant le site de schema.org, vous pourrez découvrir tout ce qu'il est possible de paramétrer.

Les éléments de mon exemple se définissent alors ainsi :

nom	url	position
Accueil	https://www.orsal.fr/	1
SEO	https://www.orsal.fr/seo/	2
Web sémantique	https://www.orsal.fr/seo/web-semantique/	3
SERP, SPIP et breadcrumb	https://www.orsal.fr/seo/web-semant...	4

Il va falloir transformer la gestion du fil d'Ariane en place sur un site SPIP pour obtenir une liste avec les informations ajoutées. Initialement le code HTML pour mon fil d'Ariane ressemble à cela :


 Accueil >
 SEO >
 Web sémantique >
 SERP, SPIP et breadcrumb

L'objectif est de transformer la génération du bloc dans le squelette SPIP pour obtenir ce type de bloc :


 
 
 
 Accueil
 
 
 

 
  > 
 
 SEO
 
 
 

 
  > 
 
 Web sémantique
 
 
 

 
  > 
 
 
 SERP, SPIP et breadcrumb

Il s'agit d'une liste de liens. Voici comment la lire.

Les données structurées schema.org sont les propriétés itemprop, itemscope et itemtype :

itemscope indique que le bloc html courant correspond à un bloc schema.org
itemtype permet de préciser le type du bloc schema.org courant
itemprop définit une propriété du bloc courant

C'est récursif, un bloc peut se retrouver l'enfant d'un autre.

Ainsi le bloc

BreadcrumbList

à un itemListElement enfant de la BreadcrumbList, de type ListItem. C'est pas clair ? Relisez doucement le source HTML, ça va venir.

En plaçant la propriété item sur la balise , cela permet de définir une propriété de type url. J'ai ajouté un bloc , juste pour porter la propriété name. Enfin pour la position, comme je n'avais pas d'élément où l'insérer, j'ai directement ajouté un bloc , qui ne s'affichera donc pas, mais sera bien présent dans le code.

Google et les données structurées

La liste des champs/propriétés possibles sont disponibles sur le site de schema.org.

Une liste plus synthétique des champs recommandés ou obligatoires, sont disponibles dans les directives pour les données structurées définies par Google.

En utilisant des données structurées sur votre site, vous améliorez la compréhension de votre site par les moteurs de recherche, donc vous en améliorez le référencement, et vous bénéficiez parfois d'un affichage optimisé (rich snippet) dans les résultats de recherche, comme l'affichage des notes sur des produits, ou les éléments d'une recette.

Outil indispensable lorsque vous travaillez les données structurées, Google propose un analyseur de code source qui vous montre le résultat de la détection par le moteur de recherche des balises sémantiques, pour tester vos données structurées.

Il vous indiquera également les erreurs que vous auriez pu commettre dans l'enchaînement des blocs. Utilisez-le pour débugger vos balises.

Pas de jaloux, les données structurées fonctionnent également chez Microsoft Bing et Yandex, entre autres.

SPIP et les données structurées

L'objectif est d'intégrer ceci à un site SPIP. J'ai fait la modification sur les pages article et rubrique pour lesquelles je voyais un intérêt à avoir un fil d'Ariane.

Pour cela, j'ai copié les fichiers article.html et rubrique.html que j'ai trouvés dans le répertoire de mon thème actuel, vers le répertoire squelette/contenu/ du site, pour surcharger les squelettes.

J'ai ensuite rechercher et remplacer le bloc hiérarchie présent dans les fichiers. Voici le morceau de squelette qui permet de générer le fil d'Ariane avec les méta données.
[(#REM) Fil d'Ariane ] <:accueil_site:> > [(#TITRE|couper{80})] [ > (#TITRE|couper{80}) ]
Le bloc
1. qui le constitue correspond à un niveau hiérarchique.
  
  Le premier élément
2. correspond à la page d'accueil. La position du premier élément doit être égale à 1.
  
  Ensuite on entre dans une boucle sur la hiérarchie des rubriques entre l'accueil du site et la page courante. Pour chaque niveau, on retrouve un bloc
3. . La position est calculée sur la balise SPIP #COMPTEUR_BOUCLE qui nous donne le numéro d'itération. On ajoute 1, avec le filtre plus {1} car le premier c'est la page d'accueil.
  
  A partir de SPIP 3.0, il existe la balise #PROFONDEUR qui indique la profondeur d'une rubrique, mais la numérotation commence à 0, et la position attendue pour le premier élément est 1. Donc je préfère garder mon système de comptage sur la boucle qui fonctionne pour toutes les versions de SPIP.
  
  Enfin, pour le dernier élément du fil d'Ariane, il s'agit de la page actuellement visitée, j'ai utilisé un lien vers la page courante pour ajouter du maillage interne important en SEO. J'ai placé le code dans le bloc optionnel, entre la balise fermante et la balise fermante , pour que la balise #TOTAL_BOUCLE contienne le nombre d'éléments trouvés dans la hiérarchie. Cela va permettre de calculer la position du dernier élément, via le filtre plus {2}.
  
  De plus ce bloc est entre crochet pour que les balises et filtres soient remplacés et calculés lors de la génération de la page.
  
  Une fois que vous avez apporté la modification sur les deux squelettes, il n'y a plus qu'à recalculer la page et vider le cache, et enfin attendre que les moteurs de recherche fassent la mise à jour.
  
  CSS & fil d'ariane
  
  Si tout s'est bien passé, vous devez obtenir une liste ordonnée qui correspond à votre fil d'Ariane. Mais pour l'instant les éléments sont les uns en dessous des autres, avec une numérotation.
  
  Pour modifier cela, j'ai utilisé un peu de CSS, dans le fichier squelette/perso.css pour surcharger le style de mon thème.
  
  #hierarchie li { list-style-type: none; margin-left: 0; display: inline; }
  
  Cela correspond à :
  - list-style-type permet de masquer la numérotation
  - margin-left permet de supprimer le décalage de la numérotation
  - display permet d'afficher chaque élément du fil d'Ariane sur la même ligne à la suite
  Pensez à rafraîchir le cache pour vérifier les modifications.
  
  Pour aller plus loin
  
  N'oubliez pas de tester le résultats de vos modifications avec l'outil de Google, pour vérifier qu'il détecte bien tous vos champs. Vous découvrirez au passage peut-être d'autres balises déjà présentes sur la page.
  
  Le champ des possibles avec les données structurées est immense et reconnu par tous les moteurs de recherche. N'hésitez pas à en abuser sur vos pages.

Theme-color : personnaliser les couleurs du navigateur mobile pour votre marque

Guillaume Orsal — 2016-03-11T16:50:33Z

La méta theme-color permet de personnaliser l'interface de navigation mobile (barre d'adresse, onglets) aux couleurs de votre marque. Découvrez comment implémenter cette meta HTML simple mais efficace sur Chrome, Safari iOS, et Windows Phone pour améliorer l'expérience utilisateur et votre cohérence visuelle sur tous les appareils.

Pourquoi implémenter theme-color ?

L'expérience utilisateur sur mobile est cruciale pour votre branding et votre SEO. La méta theme-color offre un avantage simple mais efficace : aligner l'interface de navigation aux couleurs de votre marque. Cela crée une expérience cohérente et professionnelle sur tous les navigateurs mobiles.


Utilisation de la balise meta theme-color

Implémentation multiplateforme

L'astuce est assez simple, il suffit d'ajouter un meta theme-color dans l'entête de votre page Web. Donc à l'intérieur de la balise .

Chrome et navigateurs standards

Cette meta a intégré le standard HTML, mais n'est pas encore respectée de manière identique par tous les navigateurs. Personnellement, j'ai pu constater le fonctionnement sur Android que sous Chrome et les navigateurs Chromium.

Windows Phone

Pour Windows Phone, il faudra utiliser une autre meta que le standard...

iOS Safari

Enfin sur iPhone, vous aurez en plus la possibilité de rendre translucide la barre de statut.

Standards modernes en 2025

Le support de theme-color est maintenant largement généralisé sur tous les navigateurs mobiles modernes. Chrome, Safari sur iOS, et Edge respectent cette meta comme standard. Elle fait partie des bonnes pratiques incontournables pour tout développeur souhaitant optimiser l'expérience mobile et offrir une cohérence visuelle professionnelle à ses utilisateurs.

En cherchant un peu sur le net vous trouverez d'autres personnalisations comme transformer une page Web en Web App en quelques instructions.

Erreur logrotate avec mysql-server sur Debian

Guillaume Orsal — 2015-11-05T10:47:15Z

Lors de la rotation des logs MySQL, logrotate peut échouer sur Debian et générer des erreurs répétées. Cet article explique la cause du problème et présente une solution simple pour rétablir une rotation automatique fiable.

Note historique : Cet article date de novembre 2015 (Debian Jessie). Bien que les principes restent valides, certains détails concernant logrotate et MySQL ont pu évoluer. L'approche de diagnostic décrite conserve sa pertinence pour les systèmes Debian et Ubuntu modernes.

Contexte du problème

Sur les serveurs Debian/Linux, logrotate exécute quotidiennement la rotation des fichiers journaux via un script situé dans /etc/cron.daily. Lorsque MySQL est installé, logrotate crée une configuration dédiée qui, après archivage des logs, exécute un script de post-rotation.

Ce script échoue régulièrement avec une erreur de permissions, ce qui génère des rapports envoyés par mail via cron.

Le message d'erreur type reçu est le suivant :

/etc/cron.daily/logrotate: error: error running shared postrotate script for '/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/error.log'
 run-parts: /etc/cron.daily/logrotate exited with return code 1

Diagnostic : comprendre le rôle de logrotate et debian-sys-maint

Logrotate est l'utilitaire système chargé de limiter la croissance des fichiers journaux. Il archive et compresse les anciens logs en parcourant les fichiers de configuration du répertoire /etc/logrotate.d/.

Pour la gestion de MySQL, il s'appuie sur un compte utilisateur système dédié : debian-sys-maint.

Ce compte possède les permissions minimales nécessaires à la maintenance automatique du service MySQL. Ces permissions sont référencées dans deux fichiers clés.

1. Configuration logrotate pour MySQL :

sudo cat /etc/logrotate.d/mysql-server

Ce fichier définit une variable MYADMIN qui utilise les identifiants du compte de maintenance :

MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"

2. Fichier de configuration MySQL du compte de maintenance :

sudo cat /etc/mysql/debian.cnf

Ce fichier contient les identifiants du compte debian-sys-maint :

# Automatically generated for Debian scripts. DO NOT TOUCH!
 [client]
 host = localhost
 user = debian-sys-maint
 password = xxxxxxxxxxxxxxx
 socket = /var/run/mysqld/mysqld.sock
 
 [mysql_upgrade]
 host = localhost
 user = debian-sys-maint
 password = xxxxxxxxxxxxxxx
 socket = /var/run/mysqld/mysqld.sock
 basedir = /usr

Cause racine : insuffisance de privilèges

L'erreur de post-rotation survient lorsque le compte debian-sys-maint ne dispose pas des permissions MySQL suffisantes pour exécuter les commandes d'administration nécessaires (rechargement des tables, interrogation de l'état du serveur, etc.).

Le compte système existe bien et accède au fichier de configuration, mais ses droits au niveau MySQL sont incomplets ou corrompus.

Solution : restaurer les permissions du compte debian-sys-maint

La résolution consiste à accorder au compte debian-sys-maint l'ensemble des permissions administratives requises. Cette opération doit être effectuée avec un compte disposant des droits administrateur MySQL.

Étape 1 : connexion en tant qu'administrateur MySQL

mysql -u root -p

Saisissez le mot de passe root MySQL.

Étape 2 : attribution des permissions

Exécutez les commandes SQL suivantes en remplaçant le mot de passe par celui figurant dans le fichier /etc/mysql/debian.cnf :

GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK TABLES
 ON *.* TO 'debian-sys-maint'@'localhost'
 IDENTIFIED BY 'xxxxxxxxxxxxxxx';
 FLUSH PRIVILEGES;

Les permissions accordées correspondent à :

RELOAD : recharger les tables et caches
SHUTDOWN : arrêter le serveur MySQL
PROCESS : afficher les processus serveur
SHOW DATABASES : lister les bases de données
SUPER : exécuter les opérations de maintenance
LOCK TABLES : verrouiller les tables lors des opérations de sauvegarde

Étape 3 : application immédiate des permissions

La commande FLUSH PRIVILEGES recharge les droits en mémoire et rend les changements effectifs immédiatement, sans redémarrage du serveur.

FLUSH PRIVILEGES;

Vérification

Après ces modifications, la prochaine exécution de logrotate (lors du cron quotidien) fonctionnera sans erreur.

Pour tester immédiatement sans attendre l'exécution automatique :

sudo /etc/cron.daily/logrotate

Si aucune erreur n'est affichée, le problème est résolu.

Prévention et bonnes pratiques

Maintenir à jour le compte debian-sys-maint via les mises à jour du paquet mysql-server
Surveiller les erreurs logrotate dans les logs cron : grep logrotate /var/log/syslog
Adapter les permissions sur les installations personnalisées ou durcies
Préserver le fichier /etc/mysql/debian.cnf, élément clé du bon fonctionnement de la maintenance automatisée