Règles communes à tous les scripts

• Rien n'est publié par l'agent. Il dépose des brouillons. Sur gererseul.com son compte est « contributeur », le site refuse la publication même par erreur.
• Rien ne part en production sans validation de Brice (consultant SEO). Les réécritures se font sur le site de test (staging) et attendent.
• Le texte est écrit par Claude (modèle Sonnet 5.5) qui lit à chaque fois le guide éditorial maison [gererseul-seo] : processus de Brice, erreurs juridiques à ne plus faire, checklist de relecture.
• Un appel au modèle dure au plus 25 minutes et peut être retenté trois fois en cas de panne.
• Chaque étape écrit un rapport daté dans le dossier des rapports. Rien n'est effacé : les versions avant modification sont sauvegardées.
• Les emails à Brice sont limités à deux envois automatiques : la veille sécurité du vendredi et le récapitulatif du lundi. Tout autre courrier se fait sur instruction.

Lot du lundi gererseul [hebdo.py]

Tous les lundis à 5 h ou 6 h (heure de Paris selon la saison), 5 articles demandés, déposés en brouillon sur gererseul.com. Durée environ 2 h.

• Avant de commencer, il refait l'inventaire du site (articles et pages) pour ne pas travailler sur une liste périmée.
• Il lance la veille d'actualité du jour si elle n'a pas déjà été faite.
• Il prend les sujets dans cet ordre : les actualités de la veille, puis la file de sujets saisie à la main ou par Slack, puis des idées tirées de la Search Console si le lot n'est pas plein.
• Chaque sujet repasse les contrôles même s'il avait été accepté au moment de son entrée dans la file : un article écrit entre-temps par l'équipe doit le disqualifier.
• Un sujet qui ne passe pas est noté « disqualifié » avec le motif, ou « en attente » s'il manque seulement des articles à lier. Après 3 échecs de rédaction, il est « bloqué ».
• À la fin : rapport, mise à jour de la file, message Slack à Tom et Brice, email récapitulatif à Brice.
• En plus, il réécrit jusqu'à 3 anciens articles touchés par l'actualité du jour, sur le site de test seulement.

Veille d'actualité [veille.py]

Une fois par lot, partagée entre gererseul.com et lebonbail.fr.

• Claude (modèle Opus 5.5) cherche sur le web les nouveautés du droit locatif français et les classe en majeure, notable, mineure.
• Pour chaque actualité, il propose une requête d'article et ce qui change pour le bailleur. Les actualités passent en tête de la file de sujets, parce qu'elles sont périssables.

Choix et contrôle des sujets [antidoublon.py, sujets_gsc.py, verif_positions.py, jev_selection.py]

• Anti-doublon, bloquant. Le sujet est comparé à tous les articles, pages et brouillons existants. Au-dessus d'un score de ressemblance de 0,75, il est refusé. Une exception validée à la main peut lever le refus.
• Doublon entre les deux sites, bloquant. Un sujet déjà traité pour lebonbail.fr n'est pas réécrit pour gererseul.com, et inversement, sauf accord explicite.
• Positions Google, informatif. Si le site est déjà bien placé sur la requête, l'agent le note et demande à l'article de se distinguer des pages existantes. Depuis le 29 octobre ce contrôle ne bloque plus.
• Maillage, condition d'attente. Il faut au moins deux articles de moins de deux ans sur le même thème pour y faire des liens. Sinon le sujet attend la semaine suivante.
• Search Console. Les idées de complément viennent des requêtes où le site apparaît au-delà de la 20e position avec au moins 100 affichages, en 3 à 7 mots, hors mots exclus. Une idée trop proche d'une page existante (score 0,70) est écartée.
• Avis JEV, consultatif. Un service externe de recherche sémantique donne son avis sur chaque sujet. L'article doit ensuite justifier sa décision (créer, fusionner, abandonner). Une décision autre que « créer » met le sujet « à arbitrer » par un humain.
• La file de sujets a un seuil d'alerte (5 pour gererseul, 3 pour Le Bon Bail) mais aucun script ne le lit aujourd'hui.

Rédaction d'un nouvel article [rediger.py]

Appelé par le lot du lundi, ou à la main pour un sujet précis.

• Un appel à Claude par article, avec accès à la recherche web, aux données Ahrefs et au guide éditorial. Le modèle rend un fichier structuré : titre, H1, meta description, corps, FAQ, liens, checklist.
• Contrôles automatiques bloquants : la requête visée doit être dans le titre, la meta description et le H1 ; la meta description fait entre 140 et 170 caractères ; au moins deux liens vers des articles récents du plan ; pas d'année dans l'adresse de la page ; entre 900 et 2 600 mots ; pas de sous-sous-titres (H3).
• Si une erreur est corrigible (longueur de meta, lien manquant), l'article est renvoyé une fois au modèle pour correction.
• Contrôle de prudence, non bloquant : repère les formules absolues (« toujours », « jamais »), les sanctions chiffrées sans nuance, les comparaisons de marché sans source. Ces alertes apparaissent en bandeau jaune dans le brouillon pour la relectrice.
• Lisibilité, non bloquant : phrases de plus de 30 mots, texte qui s'adresse au locataire au lieu du bailleur, année passée dans le titre.
• Erreurs de droit à ne plus commettre, inscrites dans le guide : bail verbal valable, révision du loyer seulement si le bail le prévoit, ne pas mélanger location nue et meublée, préavis bailleur 6 mois en vide et 3 mois en meublé.
• Dépôt en brouillon avec la catégorie prévue, puis message Slack à la relectrice (Cathy) avec un numéro à rappeler pour valider ou refuser.

Réécriture des anciens articles [rafraichir.py puis reecrire.py]

Tous les lundis à 7 h 30 ou 8 h 30 (heure de Paris), 10 articles demandés, sur le site de test uniquement.

• Choix des pages. Depuis le 29 septembre, l'agent suit la liste de Brice (54 pages classées par rang et par vague). Il la prend dans l'ordre et saute les pages déjà traitées, celles qui ont une date « pas avant » et celles modifiées en prod depuis moins de 60 jours. Liste épuisée : aucun lot automatique, c'est à Brice de dire la suite. L'ancienne sélection par potentiel SEO (pages en position 4 à 15 sur une requête d'au moins 100 recherches par mois) n'est utilisée que sur demande.
• Pages intouchables : la liste d'exclusions de Brice et les pages promises à une redirection ne sont jamais réécrites.
• Avant d'écrire, la version actuelle est sauvegardée en entier, et la version en ligne est relue pour mesurer ce qui change.
• Deux modes. « Mise à jour » pour les pages de Brice : titre de production conservé, mêmes sous-titres, deux ajouts au plus, longueur entre 0,9 et 1,6 fois l'original. « Refonte » : réécriture complète sur la même adresse.
• À conserver obligatoirement : l'adresse de la page, les tableaux, les images, les liens internes, les mots des requêtes qui apportent déjà des clics.
• Mêmes contrôles de forme que pour un nouvel article (meta, longueur, pas de H3 sauf en mise à jour). Les pertes de contenu et la lisibilité sont signalées sans bloquer.
• Après l'écriture sur le site de test, une relecture de contrôle vérifie que la page sert bien le nouveau texte. Un visuel est généré. L'article entre en « attente Brice » et un récapitulatif part sur Slack.
• Une page refusée par les contrôles sort de la liste et n'est pas retentée automatiquement. Elle n'est pas annoncée sur Slack.

Passe « retours » [reecrire_retours.py]

Déclenchée depuis Slack par une relectrice ou par Tom, Brice, Nicolas.

• Commande « retours N : vos remarques ». L'agent relance Claude sur l'article avec les remarques, puis redépose sur le site de test.
• Deux passes au plus en même temps, dix en file d'attente. L'identité de la personne est vérifiée avant de lancer.
• Pendant une passe retours, les contrôles de forme deviennent des avertissements, pour ne pas bloquer une correction demandée par un humain.
• À la fin, l'article revient à l'étape où il était avant la passe.

Transfert en production [transfert_prod.py]

Commande manuelle sur le serveur, jamais automatique. Simulation par défaut.

• Conditions pour transférer une réécriture : validée par Brice (ou Tom) puis par la relectrice, aucune passe en cours, site de test non modifié depuis la validation, page de production au même slug et non modifiée depuis la sauvegarde de départ.
• Un seul transfert à la fois tant que le précédent n'a pas été vérifié.
• Avant d'écrire : relecture de la production et sauvegarde complète. Après : relecture, passage en « en prod », contrôle du cache.

Bilan du lundi [bilan_reecritures.py, alerte_score.py, point_etat.py]

Lundi matin après les lots ; point d'état du mardi au vendredi.

• Compare, page par page, les 28 derniers jours de Search Console aux 28 précédents : clics, affichages, position. Un écart de position de moins d'un rang est considéré comme du bruit.
• Signale les pages qui montent, celles qui perdent des clics, et celles vues plus de 1 000 fois sans aucun clic (titre et meta à revoir).
• Limite connue : le bilan ne mesure que les pages « prêtes à publier », pas celles déjà transférées en production.
• L'alerte de score prévient Tom et Brice en message privé seulement si le classement des priorités a bougé.

Le Bon Bail [lbb_hebdo.py puis lbb_rediger.py]

Tous les lundis à midi ou 13 h (heure de Paris), 5 articles demandés, déposés en brouillon directement sur lebonbail.fr par son interface technique (pas de site de test, pas d'image).

• Inventaire du jour des articles publiés et des brouillons du site, veille d'actualité réutilisée du lot gererseul.
• Sujets : actualités d'abord (rubrique « Actualités juridiques du bail », angle bailleur et locataire), puis la file de sujets de Nicolas, Brice ou Slack.
• Mêmes contrôles qu'en face : pas de doublon avec le corpus lebonbail, pas de doublon avec gererseul, pas de sujet déjà dans le top 20 Google du site, deux articles récents à lier.
• Un appel à Claude par article, avec le même guide éditorial en lui demandant d'ignorer ce qui est propre à gererseul, et deux extraits du ton du site.
• Contrôles bloquants spécifiques : exactement 3 liens internes, une FAQ de 3 à 5 questions, aucune mention de gererseul, pas de H1 ni de H3 dans le corps, HTML limité à une liste de balises autorisées.
• L'agent ne modifie jamais un article publié sur lebonbail.fr : création de brouillons seulement, et il refuse de toucher à autre chose qu'un brouillon.
• Message privé à Cathy avec le numéro de l'article. Cathy tape « valide N » ou « refuse N : motif » dans Slack ; Brice et Tom sont alors prévenus. La publication reste manuelle.
• Récapitulatif Slack à Tom et Brice chaque lundi, même quand aucun article n'a pu être produit. Il n'y a pas d'idées de complément Search Console pour ce site : file vide, lot vide.

Commandes dans Slack [slack_pont.py]

Programme qui tourne en permanence et lit les messages adressés au bot.

• « valide N » : Tom, Brice ou Nicolas valident une réécriture, elle part chez Julie ou Marie (celle qui a le moins d'articles en cours). Une relectrice qui tape « valide N » rend l'article « prêt à publier ». Cathy valide les nouveaux articles des deux sites.
• « refuse N : motif » : l'article est marqué refusé avec le motif, Nicolas est prévenu.
• « retours N : remarques » : lance une passe retours.
• « sujet : requête, angle » : ajoute un sujet à la file après les contrôles anti-doublon. « sujet LBB : … » pour lebonbail.fr.
• « lance le lot » : lance un lot de rédaction à la main, refusé si un lot tourne déjà ou si la file est vide.
• « articles » : liste ce qui attend chaque personne.
• Ces commandes sont du code, pas du modèle. En langage courant, le bot demande à Claude de comprendre la demande puis exécute les mêmes commandes.

Auto-amélioration [auto_amelioration.py]

Tous les jours à 18 h et 19 h (heure de Paris).

• Lit les messages Slack adressés au bot dans la journée, sauvegarde le projet, lance les tests, puis laisse Claude (modèle Opus 5.5, 45 minutes au plus) modifier le code, les tests, la documentation, le guide éditorial et les files de sujets pour tenir compte des demandes.
• Après coup : vérifie que les fichiers secrets et la programmation des tâches n'ont pas changé, que tout compile et qu'aucun test ne s'est mis à échouer. Sinon, retour arrière.
• En cas de succès : enregistrement dans l'historique, redémarrage du bot Slack si besoin, message à Nicolas.
• Point d'attention : l'interdiction de toucher aux états de relecture, aux rapports et aux brouillons n'est écrite que dans la consigne donnée au modèle. Le guide de rédaction modifié le soir sert dès le lendemain matin sans relecture humaine.

Contrôles et alertes [securite.py, checkup_lundi.py, geo_suivi.py, llms_txt.py]

• Veille sécurité, le vendredi : requêtes hors sujet dans la Search Console (signe de spam), liens entrants récents depuis des domaines jetables, test de cloaking. Les mesures sont faites par le code, Claude ne fait que rédiger l'état des lieux envoyé à Brice.
• Check-up du lundi : vérifie que chaque tâche du lundi a bien tourné en lisant ses journaux, et liste les pages refusées par les contrôles.
• Le 1er du mois : relevé de visibilité dans les réponses IA (20 questions cibles) et mise à jour du fichier llms.txt destiné aux moteurs IA.